AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2021.01.15 23:32 "[Tiff] MergeRequest for discussion code style", by Kurt Schwehr
2021.01.16 01:12 "Re: [Tiff] MergeRequest for discussion code style", by Edward Lam
2021.01.16 14:56 "Re: [Tiff] MergeRequest for discussion code style", by Bob Friesenhahn
2021.01.17 06:49 "Re: [Tiff] MergeRequest for discussion code style", by William Bader
2021.01.17 07:33 "Re: [Tiff] MergeRequest for discussion code style", by Tom Lane
2021.01.17 17:43 "Re: [Tiff] MergeRequest for discussion code style", by Kurt Schwehr
2021.01.18 14:32 "Re: [Tiff] MergeRequest for discussion code style", by Edward Lam
2021.01.19 17:21 "Re: [Tiff] MergeRequest for discussion code style", by Kurt Schwehr
2021.01.19 18:57 "Re: [Tiff] MergeRequest for discussion code style", by Bob Friesenhahn
2021.01.20 20:41 "[Tiff] MergeRequest for discussion code style", by Thomas Bernard
2021.01.21 15:01 "[Tiff] MR 151 (was: Re: MergeRequest for discussion code style)", by Edward Lam

2021.01.17 07:33 "Re: [Tiff] MergeRequest for discussion code style", by Tom Lane

Is ssize_t guaranteed to hold negative values other than -1?

The POSIX spec for <sys/types.h> quoth

The type ssize_t shall be capable of storing values at least in the
range [-1, {SSIZE_MAX}].

so, per spec, no it isn't. However, that's just specs gamesmanship, because there is no hardware architecture anywhere in which a signed datatype doesn't have approximately-equal positive and negative limits. There are way more valuable ways to spend your time than pretending your code might have to run on a system where that isn't the case.

However, as noted upthread, POSIX does *not* guarantee that ssize_t is of the same bit-width as size_t. So you do have to be really careful what you use it for. 32-bit ssize_t along with 64-bit size_t seems to be entirely spec-compliant.

Is intmax_t a better option than intptr_t? Back in 16 bit 8086 MSDOS days, you could have small model code with 16 bit pointers but 32 bit longs.

Depends what you want to use it for. intptr_t should be at least as wide as either pointers or size_t, AFAICS.

regards, tom lane