Re: alternatives to 'strlcpy'

[Paul Eggert]

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.