This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 29 Jan 2016 03:48, Alexander Cherepanov wrote:
> 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.

not all functions glibc uses restrict on are in any standard, unless you
are lumping "the GNU standard" in there.

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

Attachment: signature.asc
Description: Digital signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]