From owner-freebsd-toolchain@FreeBSD.ORG Sun Mar 29 02:46:13 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25DC1F45 for ; Sun, 29 Mar 2015 02:46:13 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D54B8E55 for ; Sun, 29 Mar 2015 02:46:12 +0000 (UTC) Received: (qmail 30853 invoked from network); 29 Mar 2015 02:46:05 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 29 Mar 2015 02:46:05 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sat, 28 Mar 2015 22:46:05 -0400 (EDT) Received: (qmail 7239 invoked from network); 29 Mar 2015 02:46:05 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 29 Mar 2015 02:46:05 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id CD95D1C439E; Sat, 28 Mar 2015 19:45:58 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: svn commit: r280636 - head/include Date: Sat, 28 Mar 2015 19:46:03 -0700 Message-Id: <111667CF-2A20-48CE-80F7-3F89FD274EB6@dsl-only.net> To: brde@optusnet.com.au Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org, dim@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 02:46:13 -0000 With reference to Dimitry Andric's Thu Mar 26 14:41:43 UTC 2015 note ... > On 26 Mar 2015, at 14:20, Tijl Coosemans wrote: > >=20 > > On Thu, 26 Mar 2015 17:37:53 +1100 (EST) Bruce Evans 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 () 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 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): 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 is not supposed to include . 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. 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