Re: strscpy

Do we really need that many functions to copy a string?

Personally I find strscpy() lame, because it does not allow for embedde NUL characters.


> Am 29.05.2020 um 20:55 schrieb Maxime Villard <[email protected]>:
> 
> Le 29/05/2020 à 20:49, Maxime Villard a écrit :
>> Le 29/05/2020 à 20:36, matthew green a écrit :
>>>>>> I would want to keep the difference minimal between the two. I think
>>>>>> that the
>>>>>> version that returns -1 is nice and addresses the concern. What do you
>>>>>> think?
>>>>> 
>>>>> Personally I have got no strong opinion. I would change "size > INT_MAX"
>>>>> to "size > SSIZE_MAX".
>>>>> 
>>>>> Returning -1 instead of -EINVAL and -E2BIG is good, as there few users
>>>>> who check return value at all, and if so, they check whether it is less
>>>>> than 0.
>>>> 
>>>> I have updated my patch:
>>>> 
>>>>     https://m00nbsd.net/garbage/libkern/strscpy.diff
>>>> 
>>>> We simply return -1. Will commit soon unless there is valid objection.
>>> 
>>> i strongly object.
>>> 
>>> please don't commit more dual-return value APIs.
>>> 
>>> kre's point about it is 100% valid.  they're extremely
>>> dangerous.
>> I have still not seen any valid technical reason why they are "dangerous".
>> Now they're suddenly "extremely dangerous", but you fail to explain how.
>>> i spent a couple of months tracking down a
>>> mismatch between linux and netbsd errno values that
>>> happens because linux APIs regularly return "-errno",
>>> and we (bsd generally, not just netbsd) have avoided
>>> that idiom in most places by design.
>> You did notice that I am _not_ returning a negative errno, right?
>> This is an anecdote about Linux-to-BSD mishaps, caused by Linux using
>> negative errnos. I could easily quote you a hundred BSD-to-BSD mishaps
>> I've seen in imported subsystems and drivers.
>> Maxime
> 
> PS: and I will still move forward unless I hear a valid technical
> objection.