[PATCH][BZ 17979][BZ 17721] Fix issues with sys/cdefs.h and uchar.h when using non-gcc compiler.

[Alexander Cherepanov]

On 2016-01-29 03:58, Mike Frysinger wrote:
>>>>> wouldn't it also assist automated tools like linters/static analyzers ?
>>>>
>>>> If they hardcode information about particular functions, the qualifiers in
>>>> the headers are irrelevant.  If not, even having restrict qualifiers on
>>>> the parameters in the function definitions is only useful when you look at
>>>> the body of the definitions as well, unless you apply heuristics beyond
>>>> what is supported by the standard.
>>
>> I would add that for an analyzer to depend on a specific implementation
>> is a bit risky. The meaning of the restrict qualifier on the parameters
>> of a libc function depends on the description of the function in the
>> standard, not on any implementation.
>
> not all functions glibc uses restrict on are in any standard, unless you
> are lumping "the GNU standard" in there.

It doesn't matter. My point is that you have to work from the 
description instead of implementation. The C standard seems to impose 
minimal restrictions so there would be no difference between the 
description and any conforming implementation in many cases. For 
contrast consider proposed strlcpy/strlcat -- the last revision of their 
description is intentionally more strict than their implementation. The 
whole point of this distinction is to enable tools to catch problematic 
uses.

>>>> Remember that if a function has two restricted pointer arguments (that are
>>>> restricted in the definition), this does *not* mean that they don't alias
>>>> - only that *if* a particular execution of the function modifies some
>>>> elements pointed to by one of the pointers, those elements are not also
>>>> accessed other than through that pointer.  (But it's completely valid to
>>>> have two restricted pointers to the same array, one only used to access /
>>>> modify odd-numbered elements of that array, and the other one only used to
>>>> access / modify even-numbered elements of that array.  Now, static
>>>> analyzers might reasonably consider that dubious usage that should be
>>>> diagnosed.)
>>>
>>> i think having analyzers warn about that by default is a sane position.
>>> i would expect that such usage is more commonly an unintended mistake
>>> rather than the function actually has such esoteric behavior.  i don't
>>> think any of the glibc functions are written in this manner and expect
>>> the pointers to be distinct memory locations.
>>
>> What about strncat? I think this:
>>
>>     char s[10] = "abc";
>>     strncat(s, s, 2);
>>
>> is fine according to C11.
>
> linters/static analyzers aren't about doing standard validation.  if i
> saw that snippet, i would assume an accidental bug, or pointless code
> and should be deleted.  you don't run random hacks through linters, you
> run code you want to send to production through them.

I guess opinions will differ.

1. Personally, I would appreciate the distinction between definite 
standard violations and doubtful/risky code.

2. The stylistic preferences differ greatly. You call it a hack, others 
will call it a clever trick (though a couple of ifs and assignments in 
between to make the example code non-pointless).

But we can consider something much more real: glibc code contains many 
cases of undefined behavior (according to C11). I consider it bugs 
unwanted in production (maybe with the exception of strlen) but it's not 
clear to me what is the POV of the project on this. E.g., are bug 
reports about UB are welcome?

-- 
Alexander Cherepanov