On 09/28/2017 12:36 PM, Dmitry Selyutin wrote:
ptrdiff_t is not a good choice here, > because it represents not length, but
difference between pointers
They're the same concept in C. In 7th Edition Unix strlen returned int,
and this was better than having it return an unsigned type due to common
problems with wraparound arithmetic and comparisons with unsigned types.
In GNU Emacs source code, the general style has been to prefer signed
integers for indexes and sizes and the like, and this has helped us gain
reliability because we can catch integer overflows better by compiling
with -fsanitize=undefined, bugs that we couldn't catch so easily if we
used unsigned integers.
This is why I suggest ptrdiff_t for new low-level APIs. Although it
limits object size to PTRDIFF_MAX, that limitation is present already
because in practice behavior is undefined when you compute p1-p2 when
((char *) p1 - (char *) p2) does not fit into ptrdiff_t, which means
that objects larger than PTRDIFF_MAX are dangerous and should be avoided
anyway.
ssize_t is a worse choice for portable software, as it is not in
stddef.h and on a few old platforms ssize_t is narrower than size_t
(POSIX allows this).
All this is moot of course if any new function returns bool or void, as
I suspect it should.
