[Top][All Lists]

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

Re: alternatives to 'strlcpy'

From: Dmitry Selyutin
Subject: Re: alternatives to 'strlcpy'
Date: Thu, 28 Sep 2017 22:36:39 +0300

>> 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 difference between pointer in some way, but well, I think that's 
not the first allegory that comes to mind when one talks about strings. As for 
me, the only reason to avoid ssize_t is a dependency to stddef.h, but well, I 
think it is going to be used in most projects anyway, especially if these 
projects are somewhat complex. I thought size_t also comes from stddef, but I 
may be wrong. :-)

>   - The argument order.
That's also I think largely a historical issue. BTW, on x86_64 it makes some 
sense due to use of $rdi/$rsi. The only register that must be copied is $rcx. 
After then, one can implement memcpy/strcpy in just a few lines of assembly. 
Anyway, I agree that the argument order should better be changed, to avoid 
confusing strgcpy with its relatives (strncpy, strlcpy, strscpy).

>   If DSTSIZE is 0, it returns -1 and sets errno to EINVAL.
>   If DSTSIZE is nonzero and the result does not fit, it produces a NUL-
>   terminated truncated result, and returns -1 and sets errno to E2BIG.
I really dislike the idea of setting errno, since it involves thread-local 
storage. I know it's a "cold" path, but nevertheless, I really favor returning 
error codes if it is possible. And it is possible with ssize_t. Moreover, more 
modern POSIX functions do actually favor returning error code directly.

Anyway, I really think it is a good idea to provide yet another function, for 
me it seems the most logical choice; I cannot guess what "g" in strgcpy means 
though. Guarded? GNU? Generic? Godlike? :-)
The only possible reason to avoid doing such change is that some people may 
think that these Open Source guys went crazy and invented at least three 
functions to copy strings (four, including strscpy from the Linux kernel); 
moreover, since some people do not actually know the difference between strcpy 
and strcat, the situation is even worse. :-)

With best regards,
Dmitry Selyutin

Attachment: signature.asc
Description: This is a digitally signed message part.

reply via email to

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