With reference to Dimitry Andric's Thu Mar 26 14:41:43 UTC 2015 note ... > On 26 Mar 2015, at 14:20, Tijl Coosemans <tijl at freebsd.org> wrote: > > > > On Thu, 26 Mar 2015 17:37:53 +1100 (EST) Bruce Evans <brde at > > optusnet.com.au> wrote: > >> On Wed, 25 Mar 2015, Pedro Giffuni wrote: > ... > >>> The reason why I had to revert the change is actually a systematic > >>> bug in gcc: during it's build process gcc generates a new cdefs.h > >>> from our headers. Attempting to use an older gcc from ports > >>> that was build with the broken mono-parameter __nonnull() ended > >>> up causing breakage in any code using signal.h or pthreads.h. > >> > >> I see. gcc's "fixed" headers cause lots of problems. > > > > I've complained about this multiple times in the past. The gcc ports > > should not install these "fixed" headers. > > Indeed. See also this recent discussion on -current: > > https://lists.freebsd.org/pipermail/freebsd-current/2015-March/055111.html > > where a "fixed" stdio.h (from a gcc port) causes trouble. > > -Dimitry >
Preface: I do not want to be taken as indicating that GCC manipulation of headers to make alternates is a good thing: it is not. I expect that such creates lots of problems, as has been indicated. But I also maintain that the code sighted in https://lists.freebsd.org/pipermail/freebsd-current/2015-March/055111.html also has a problem relative to the C language standards (various vintages), independent of any gcc header manipulation of the C standard headers or FreeBSD headers. Setting up the context for the point: The code references the type name va_list from a #include'd header (<printf.h>) that is not from a C standard in order to declare a function that is not from a C standard (__xvprintf). The point: That code does so before any #include <stdarg.h> happens in the #include sequence. Under the C standards one must include a standard header before one's own code can validly refer to anything that the standard header officially defines or declares. For the C standard headers themselves (various C standard vintages): <stdio.h> is supposed to declare the likes of vfprintf, vprintf, and vsprintf but not the public name va_list, just using a private-named/anonymous synonym for the type to declare the functions. Also <stdio.h> is not supposed to include <stdargs.h>. The standard headers have mutual independence (so include-order-independence) and idempotent status (include-repeatability) only relative to each other, not relative to one's own code that references the standard header content. <stdarg.h> is the only C standard header that is supposed to define the public name va_list (and so the one publicly available synonym for the type in question). Where I get this from: Much of my background information for this and the terminology that I use for the C library is from The Standard C Library by P. J. Plauger, Copyright 1992. But I've not noticed any later ANSI/ISO/IEC material indicating that the above material has changed status in more recent vintages of the standard. I could be wrong since I've not tried to be comprehensive about analyzing all the changes. I have a copy of BS ISO/IEC 9899:1999 (with Technical Corrigendum 1 incorporated and with the Revision 5.10 C Rationale) but not of the C11 vintage of the standard. I'll shut-up on this point after this note (unless I get a question/request) and I'll leave it to official FreeBSD folks for any further consideration of what to do about the code sighted in https://lists.freebsd.org/pipermail/freebsd-current/2015-March/055111.html . Attempting to present my claim a 3rd time seems enough, likely overkill already. I sent this note to freebsd-toolchain as it seemed more relevant than freebsd-current for the issue involved. === Mark Millard markmi at dsl-only.net _______________________________________________ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
