[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: alternatives to 'strlcpy'

From: Paul Eggert
Subject: Re: alternatives to 'strlcpy'
Date: Thu, 28 Sep 2017 15:23:32 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]