From owner-freebsd-current@FreeBSD.ORG Sun Mar 22 15:46:06 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 62775410 for ; Sun, 22 Mar 2015 15:46:06 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (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 EE648E99 for ; Sun, 22 Mar 2015 15:46:05 +0000 (UTC) Received: (qmail 20399 invoked from network); 22 Mar 2015 15:46:04 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 22 Mar 2015 15:46:04 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sun, 22 Mar 2015 11:46:04 -0400 (EDT) Received: (qmail 22936 invoked from network); 22 Mar 2015 15:46:03 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 Mar 2015 15:46:03 -0000 X-No-Relay: not in my network 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 1B5B11C43BD; Sun, 22 Mar 2015 08:46:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: 11.0-CURRENT -r276514: lib/libpjdlog/pjdlog.c has after From: Mark Millard In-Reply-To: Date: Sun, 22 Mar 2015 08:46:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <17E1F4C9-EB45-4A14-B3A6-97B016A8AD4D@dsl-only.net> To: Dimitry Andric X-Mailer: Apple Mail (2.2070.6) X-Mailman-Approved-At: Sun, 22 Mar 2015 16:29:41 +0000 Cc: freebsd-current@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 15:46:06 -0000 Dimitry Adnric wrote: > You should be able to include standard headers (or at least, headers = in > /usr/include) in any order, and includes , which > then defines the correct types. Another of the ANSI/ISO-C rules is: You must include a standard header = before you refer to anything that it officially defines or declares. = (The Standard C Library by P. J. Plauger, Copyright 1992, page 7, 3rd = bullet under "using headers".) Part of that status is tied to the following: In a correct ANSI/ISO-C = implementation defines one or more synonyms for va_list using = names from the class of reserved-to-implementation names in order to = declare vprintf, vfprintf, and vsprintf. But does not declare = va_list itself. No ANSI/ISO-C header is allowed to declare/define extra = official-public-name items that are only officially from other headers. = (Page 12.) [There are also 2 more major principles for standard headers: mutual = independence (so order-independence) and idempotent status = (repeatability).] Only is allowed to declare that exact name (va_list) --the = synonym with the official, public name. va_list is one of many things = with this private-name vs public-name synonym structure in ANSI/ISO-C. is not one of the 24 (C99) or so ANSI/ISO-C standard headers = (by name). Nor is __xvprintf from the C standard. So the #include that I referenced is violating the standard by = referring to something from before that header has been = included. The existing source code is in error relative to ANSI/ISO-C. Also: Using the order #include #include in pjdlog.c does get rid of the problem. (As it should, per the above.) But I do not know that there is any official claim that the environment = is to strictly follow ANSI/ISO-C for such points. There may be other = principles instead. How comprehensive/complete is /usr/include header analogy to the = ANSI/ISO-C rules? Does FreeBSD bother with having the private-named = synonyms for headers that do not official declare/define something? Is = FreeBSD as explicit as ANSI/ISO-C about where official definitions are = and are not in headers? (Idempotent headers are the easier part to set = up. Mutual-independence gets into private-named synonym techniques in = order to deal with public names being only in the official places.) (ANSI/ISO-C does have examples of some specific things explicitly being = declared/defined (public names) in more than one header: more examples = where using reserved-name guard macros to gain idempotent status and = order independence can be done.) Note: Much of my background information for this and the terminology = that I use is from The Standard C Library by P. J. Plauger, Copyright = 1992. But I've not noticed any later ANSI/ISO material indicating the = the above has changed status in more recent vintages of the standard. I = could be wrong since I've not tried to be comprehensive about analyzing = changes. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-22, at 05:14 AM, Dimitry Andric wrote: On 22 Mar 2015, at 03:45, Mark Millard wrote: ... > Looking at the sources suggests that is explicitly in the = #include sequence too late to guarantee va_args a definition at the = point of its use in #include : is #include'd in = pjdlog.c in the line after #include and printf.h itself does = not (directly) include stdarg.h . >=20 > /usr/include/printf.h (the LOOK HERE is my message editing) : >> ... >> #include >> #include /// <<<<< LOOK HERE for lack of >> ... >> int __xvprintf(FILE *fp, const char *fmt0, va_list ap); >> ... >=20 > /usr/srcC/lib/libpjdlog/pjdlog.c (the LOOK HERE's are my message = editing) : >> ... >> #include >> __FBSDID("$FreeBSD: head/lib/libpjdlog/pjdlog.c 258791 2013-12-01 = 09:41:06Z pjd $"); >>=20 >> #include >> #include >> #include >> #include >> #include >>=20 >> #include >> #include >> #include >> #include >> #include /// <<<<< LOOK HERE >> #include /// <<<<< LOOK HERE for stdarg.h vs. printf.h = order You should be able to include standard headers (or at least, headers in /usr/include) in any order, and includes , which then defines the correct types. However, there is a problem in the gcc ports. What happens, is that the gcc port uses its *own* munged versions of stdio.h and stdarg.h, and includes them instead of the system versions. For example, the gcc 4.7 port has this "fixed" version of stdio.h: = /usr/local/lib/gcc47/gcc/i386-portbld-freebsd11.0/4.7.4/include-fixed/stdi= o.h which explicitly *disables* our declaration of __va_list (the type which va_list is based on): typedef __va_list __not_va_list__; For functions like vprintf(), it replaces __va_list by a GNU builtin variant, for example: int vprintf(const char * __restrict, __gnuc_va_list); However, it does not properly declare the regular va_list type, and then things break in interesting ways. I think the ports should not attempt to "fix" our include files. -Dimitry