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