[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 02:43, Mike Frysinger wrote:
> On 28 Jan 2016 23:16, Joseph Myers wrote:
>> On Thu, 28 Jan 2016, Mike Frysinger wrote:
>>> On 28 Jan 2016 22:52, Joseph Myers wrote:
>>>> On Thu, 28 Jan 2016, Dwight Guth wrote:
>>>>> Okay but if so, then why put the __restrict in the header files at all
>>>>> if it doesn't really matter? And why put it there only if the compiler
>>>>> is gcc?
>>>>
>>>> Effectively it serves as documentation of intent for people reading the
>>>> headers (much like the argument names with __ prefixes).
>>>
>>> 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.

>> 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.

-- 
Alexander Cherepanov