[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
signature.asc
Description: This is a digitally signed message part.
- Re: new module 'strlcpy', (continued)
- Re: new module 'strlcpy', Bruno Haible, 2017/09/27
- Re: new module 'strlcpy', Bruno Haible, 2017/09/27
- Re: new module 'strlcpy', Jim Meyering, 2017/09/27
- Re: new module 'strlcpy', Bruno Haible, 2017/09/28
- Re: new module 'strlcpy', Paul Eggert, 2017/09/28
- Re: new module 'strlcpy', Paul Eggert, 2017/09/27
- Re: new module 'strlcpy', Dmitry Selyutin, 2017/09/28
- Re: new module 'strlcpy', Tim Rühsen, 2017/09/28
- Re: new module 'strlcpy', Paul Eggert, 2017/09/28
- Re: alternatives to 'strlcpy', Bruno Haible, 2017/09/28
- Re: alternatives to 'strlcpy',
Dmitry Selyutin <=
- Re: alternatives to 'strlcpy', Paul Eggert, 2017/09/28
- Re: alternatives to 'strlcpy', Paul Eggert, 2017/09/28
[PATCH 6/6] uniname/uniname-tests: integer overflow fix, Paul Eggert, 2017/09/25
Re: [PATCH 1/6] parse-datetime, posixtm: avoid uninit access, Thien-Thi Nguyen, 2017/09/26