Re: alternatives to 'strlcpy'

2017-09-28 Thread 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 comm

Re: alternatives to 'strlcpy'

2017-09-28 Thread Paul Eggert
On 09/28/2017 11:39 AM, Bruno Haible wrote: in BSD, it is common practice to try a call with a fixed-size stack-allocated or statically allocated buffer, and try dynamic memory only when this first attempt fails. This doesn't match my experience with BSD application code, where the most common

Re: alternatives to 'strlcpy'

2017-09-28 Thread Dmitry Selyutin
>> Though I would change its ssize_t >> to ptrdiff_t, so that it depends only on stddef.h. > - The mixed use of ssize_t vs. size_t. What's wrong with ssize_t? As for me, ptrdiff_t is not a good choice here, because it represents not length, but difference between pointers. String length IS a d

Re: alternatives to 'strlcpy'

2017-09-28 Thread Bruno Haible
Paul Eggert wrote: > If you really want a function whose semantics are like strlcpy's but has > __warn_unused_result__ semantics ..., then I suppose we could > invent one and use it for Gnulib. But we should not call it strlcpy Yes, I do want such a function for copying a string to a bounded mem