From owner-freebsd-ppc@FreeBSD.ORG Sun Mar 22 18:46:15 2015 Return-Path: Delivered-To: freebsd-ppc@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 52BF148F for ; Sun, 22 Mar 2015 18:46:15 +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 0B8BD382 for ; Sun, 22 Mar 2015 18:46:14 +0000 (UTC) Received: (qmail 8319 invoked from network); 22 Mar 2015 18:46:13 -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 18:46:13 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sun, 22 Mar 2015 14:46:13 -0400 (EDT) Received: (qmail 24716 invoked from network); 22 Mar 2015 18:46:13 -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 18:46:13 -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 B91D21C43BE; Sun, 22 Mar 2015 11:46:08 -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 11:46:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3F203482-E83F-4D32-88FD-E47E1F773971@dsl-only.net> References: <17E1F4C9-EB45-4A14-B3A6-97B016A8AD4D@dsl-only.net> To: Dimitry Andric X-Mailer: Apple Mail (2.2070.6) Cc: pjd@FreeBSD.org, FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 18:46:15 -0000 One point of rather bad wording on my part in the prior note: > private-named synonyms for headers do not official declare/define = something should have been more like (capitalizing replacements/additions): private-named synonyms for things IN THOSE headers that do not = officialLY declare/define them with public names So in its context: Does FreeBSD bother with having the private-named synonyms for things in = those headers that do not officially declare/define them with public = names? (Consider any example of not even needing to name the no-public-name = synonym as an extreme form of private-name, just to make the wording = shorter generally.) I dropped freebsd-current@freebsd.org as not worth moderator activity = for this note. May be I should join but history would suggest I'd have = little activity there. And my activity would likely be too far out of = the ordinary for the use that freebsd-current@freebsd.org is normally = put to. I do not want to interfere with that normal activity when I = happen to have a burst of activity. By contrast freebsd-ppc@freebsd.org (as an example) is not normally very = busy. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-22, at 08:46 AM, Mark Millard = wrote: 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