This is the mail archive of the
libc-alpha@sourceware.org
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: Dwight Guth <dwight dot guth at runtimeverification 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: Thu, 28 Jan 2016 17:08:24 -0600
- 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>
Yes, actually. A dynamic analysis tool (like the one I am developing)
that uses the GCC preprocessor on this header file to try to decide
the types of functions in order to decide whether they are
restrict-qualified and therefore subject to the restrictions of
restrict-qualified pointers would be highly interested in this
information.
It also seems strange to me to be declaring functions in header files
with different types than are mandated by the standard just because it
won't matter in most cases... It also sounds to me like a highly
subtle bug waiting to happen. Can you guarantee that in the entire C
standard, there isn't anywhere in it where having the wrong qualifiers
on a function declaration might have some kind of impact on which
programs are well-defined or not, or on the behavior of a program? Can
you guarantee that no such cases will continue to exist in all future
revisions of the C standard? What happens when someone uses __restrict
someday in a situation where it does matter (e.g. if the next version
of C introduces a "char * restrict *" parameter somewhere), and
doesn't know anything about this discussion?
On Thu, Jan 28, 2016 at 4:58 PM, Mike Frysinger <vapier@gentoo.org> 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 ?
> -mike