-
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 06:49 "Re: [Tiff] MergeRequest for discussion code style", by William Bader
-
2021.01.16 14:56 "Re: [Tiff] MergeRequest for discussion code style", by Bob Friesenhahn
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