Date: Sat, 28 Mar 2015 19:46:03 -0700 From: Mark Millard <markmi@dsl-only.net> To: brde@optusnet.com.au Cc: freebsd-toolchain@freebsd.org, dim@FreeBSD.org Subject: svn commit: r280636 - head/include Message-ID: <111667CF-2A20-48CE-80F7-3F89FD274EB6@dsl-only.net>
index | next in thread | raw e-mail
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.nethome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?111667CF-2A20-48CE-80F7-3F89FD274EB6>