This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH][BZ 17979][BZ 17721] Fix issues with sys/cdefs.h and uchar.h when using non-gcc compiler.
- From: Alexander Cherepanov <ch3root at openwall dot com>
- To: Joseph Myers <joseph at codesourcery dot com>, Dwight Guth <dwight dot guth at runtimeverification dot com>, libc-alpha at sourceware dot org
- Date: Fri, 29 Jan 2016 03:48:14 +0300
- Subject: Re: [PATCH][BZ 17979][BZ 17721] Fix issues with sys/cdefs.h and uchar.h when using non-gcc compiler.
- Authentication-results: sourceware.org; auth=none
- References: <27c31890079f41775175b94a4abedb0c dot squirrel at server316 dot webhostingpad dot com> <alpine dot DEB dot 2 dot 10 dot 1601282115100 dot 6102 at digraph dot polyomino dot org dot uk> <CACLXh_1_dQ5D1QrKQN0pVPzt001WmS4BgwcKZkULK8XnbEMb+g at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1601282246340 dot 6102 at digraph dot polyomino dot org dot uk> <CACLXh_3rAudocTEbtZQpVoDcWgm_ww3KcX6j9XCkSRTZVPTUMg at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1601282251350 dot 6102 at digraph dot polyomino dot org dot uk> <20160128225845 dot GE14840 at vapier dot lan> <alpine dot DEB dot 2 dot 10 dot 1601282311351 dot 6102 at digraph dot polyomino dot org dot uk> <20160128234356 dot GH14840 at vapier dot lan>
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
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
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 = "abc";
strncat(s, s, 2);
is fine according to C11.