[Mesa-dev] [PATCH mesa 00/13] Make standard function available on non-standard platforms

[Jose Fonseca]

On 21/11/2018 21:17, Ian Romanick wrote:
> On 11/21/2018 12:16 PM, Jose Fonseca wrote:
>>>     util: use standard name for strncat()
>>
>>>     util: use standard name for strncmp()
>>>     util: use standard name for strcmp()
>>>     util: use standard name for strchr()
>>>     util: use standard name for sprintf()
>>>     util: use standard name for vasprintf()
>>>     util: use standard name for vsprintf()
>>>     util: use standard name for snprintf()
>>>     util: use standard name for vsnprintf()
>>
>>
>> Generally I agree with the principle of using standard functions, and
>> provide drop-in replacements for the systems where they are broken.  It
>> leads to less friction, less need to learn new things.
>>
>>
>> But C string functions is IMO a special case, because the standard
>> functions are so poorly designed, and make writing correct and secure
>> code so dawm difficult:
>>
>> - snprintf doesn't write the null char
>>
>> - strncat n parameter is awkard to use
>>
>> -  vasprintf have different return codes on different systems.
>> According to GNU manpages, it's not even C or POSIX.
>>
>>
>> And a standard for the sake of standard is just silly.
>>
>>
>> So IMO, if people care and have the time to uniformize these things, I
>> think they should move away standard C functions, and write some sane C
>> string manipulation abstraction/helpers.  And we should make GCC throw
>> warnings every time people try to use the standard C string functions.
>>
>>
>>>   All of these functions appear to have been added by 131a1fbc91725.  I've
>> added Jose to CC since he wrote it.  [...]
>>
>>
>>>   That doesn't give much insight. :(
>>
>>
>>> :(
>>
>>
>> *sigh*
>>
>>
>> The reason for adding was in b1922de9f3478869c6788ef4e954c06c20e7aa9c .
> 
> Right... I was more thinking about the str* functions than the *printf
> functions.  Locale problems with scanf / printf are real on every
> platform.  We had issues with this in the GLSL parser due to "." vs ","
> as the ones to tenths separator in floating point numbers.  Other
> *printf portability problems are real too.  I don't think there's any
> variation with strchr or strstr, though. :)
> 
> Specifically, I (and I guess Emil also) propose removing the wrappers for:
> 
>   - strchr
>   - strstr
>   - strcmp (does this have locale issues?)
>   - strncmp (does this have locale issues?)
>   - strncat
> 
> And leave the rest for at least the time being.

For those, yes, it should be fine.

I'm not 100% sure if MSVC provides them all, but we can always fallback 
to a #define where not.

strcmp/strncmp don't seem to consider locale, and we typically only use 
them for ASCII string equality comparison anyway.

Jose