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

[Mike Frysinger <vapier at gentoo dot org>]

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

i don't see an issue with allowing the headers to use keywords that are
supposed to exist according to the standard, even if we don't know the
exact compiler that is in use (i.e. non-gcc).
-mike

Attachment: signature.asc
Description: Digital signature