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: Dwight Guth <dwight dot guth at runtimeverification dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Dwight Guth <dwight dot guth at runtimeverification dot com>, libc-alpha at sourceware dot org
- Date: Thu, 28 Jan 2016 16:20:15 -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>
Thank you for drawing that to my attention. You are correct that this
means that my original issue that caused me to create this part of the
patch is in fact well defined. However, this still seems like an issue
of correctness to me. I can't seem to find any explicit paragraph in
the standard saying that, e.g. fprintf must be declared with the type:
int fprintf(FILE * restrict stream, const char * restrict format, ...);
but I assume that that is implied, otherwise we could give any of the
functions in the library any signature as long as they broadly
followed the requirements of their corresponding subclause, which
seems wrong to me.
On Thu, Jan 28, 2016 at 3:19 PM, Joseph Myers <email@example.com> wrote:
> On Thu, 28 Jan 2016, Dwight Guth wrote:
>> Glibc strips __restrict from the prototypes of C library functions in this
>> case. This is incorrect if the compiler is a C99-compliant compiler, because
>> C99 includes the restrict keyword and uses it in the declaration of a number
>> of functions in the C library. This leads to undefined behavior because
>> the definitions of those functions were defined with the restrict keyword,
>> which makes their type signatures incompatible with their declaration,
>> a violation of C99 sec. 6.2.7 paragraph 2. The same thing occurs with the
> This affects hardly any functions, if any at all, because qualifiers on
> function argument types are ignored for the purposes of compatibility
> (188.8.131.52#15). For a function to be affected it would need a restrict
> qualifier that isn't directly on the argument type itself (type *restrict
> *param, for example).
> Joseph S. Myers