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>
next in thread | raw e-mail | index | archive | help
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: > >=20 > > 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. > >>=20 > >> I see. gcc's "fixed" headers cause lots of problems. > >=20 > > I've complained about this multiple times in the past. The gcc = ports > > should not install these "fixed" headers. >=20 > Indeed. See also this recent discussion on -current: >=20 > = https://lists.freebsd.org/pipermail/freebsd-current/2015-March/055111.html= >=20 > where a "fixed" stdio.h (from a gcc port) causes trouble. >=20 > -Dimitry >=20 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. =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?111667CF-2A20-48CE-80F7-3F89FD274EB6>