Re: 11.0-CURRENT -r276514: lib/libpjdlog/pjdlog.c has stdarg.h after printf.h
On 22 Mar 2015, at 03:45, Mark Millard mar...@dsl-only.net wrote: ... Looking at the sources suggests that stdarg.h is explicitly in the #include sequence too late to guarantee va_args a definition at the point of its use in #include printf.h : stdarg.h is #include'd in pjdlog.c in the line after #include printf.h and printf.h itself does not (directly) include stdarg.h . /usr/include/printf.h (the LOOK HERE is my message editing) : ... #include stdio.h #include wchar.h /// LOOK HERE for lack of stdarg.h ... int __xvprintf(FILE *fp, const char *fmt0, va_list ap); ... /usr/srcC/lib/libpjdlog/pjdlog.c (the LOOK HERE's are my message editing) : ... #include sys/cdefs.h __FBSDID($FreeBSD: head/lib/libpjdlog/pjdlog.c 258791 2013-12-01 09:41:06Z pjd $); #include sys/types.h #include sys/socket.h #include sys/un.h #include netinet/in.h #include arpa/inet.h #include assert.h #include errno.h #include libutil.h #include limits.h #include printf.h /// LOOK HERE #include stdarg.h /// 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 printf.h includes stdio.h, 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/stdio.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 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: 11.0-CURRENT -r276514: lib/libpjdlog/pjdlog.c has stdarg.h after printf.h
Dimitry Adnric wrote: You should be able to include standard headers (or at least, headers in /usr/include) in any order, and printf.h includes stdio.h, 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 stdio.h 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 stdio.h 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 stdargs.h 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. printf.h 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 printf that I referenced is violating the standard by referring to something from stdargs.h before that header has been included. The existing source code is in error relative to ANSI/ISO-C. Also: Using the order #include stdarg.h #include printf.h 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. === Mark Millard markmi at dsl-only.net On 2015-Mar-22, at 05:14 AM, Dimitry Andric dim at FreeBSD.org wrote: On 22 Mar 2015, at 03:45, Mark Millard markmi at dsl-only.net wrote: ... Looking at the sources suggests that stdarg.h is explicitly in the #include sequence too late to guarantee va_args a definition at the point of its use in #include printf.h : stdarg.h is #include'd in pjdlog.c in the line after #include printf.h and printf.h itself does not (directly) include stdarg.h . /usr/include/printf.h (the LOOK HERE is my message editing) : ... #include stdio.h #include wchar.h /// LOOK HERE for lack of stdarg.h ... int __xvprintf(FILE *fp, const char *fmt0, va_list ap); ... /usr/srcC/lib/libpjdlog/pjdlog.c (the LOOK HERE's are my message editing) : ... #include sys/cdefs.h __FBSDID($FreeBSD: head/lib/libpjdlog/pjdlog.c 258791 2013-12-01 09:41:06Z pjd $); #include sys/types.h #include sys/socket.h #include sys/un.h #include netinet/in.h #include arpa/inet.h #include assert.h #include errno.h #include libutil.h #include limits.h #include printf.h /// LOOK HERE #include stdarg.h /// 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 printf.h includes stdio.h, 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/stdio.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
11.0-CURRENT -r276514: lib/libpjdlog/pjdlog.c has stdarg.h after printf.h
Basic context (more details later): # freebsd-version -ku; uname -apKU 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r279514M: Sat Mar 21 05:15:23 PDT 2015 root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc powerpc64 1100062 1100062 I was seeing what would happen if I tried gcc5 for buildworld/buildkernel and gcc5 reported the following. The problem: /usr/local/bin/gcc5 -fpic -DPIC -O2 -pipe -I/usr/srcC/lib/libpjdlog -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/srcC/lib/libpjdlog/pjdlog.c -o pjdlog.So In file included from /usr/srcC/lib/libpjdlog/pjdlog.c:44:0: /usr/include/printf.h:118:44: error: unknown type name 'va_list' int __xvprintf(FILE *fp, const char *fmt0, va_list ap); ^ Looking at the sources suggests that stdarg.h is explicitly in the #include sequence too late to guarantee va_args a definition at the point of its use in #include printf.h : stdarg.h is #include'd in pjdlog.c in the line after #include printf.h and printf.h itself does not (directly) include stdarg.h . /usr/include/printf.h (the LOOK HERE is my message editing) : ... #include stdio.h #include wchar.h /// LOOK HERE for lack of stdarg.h ... int __xvprintf(FILE *fp, const char *fmt0, va_list ap); ... /usr/srcC/lib/libpjdlog/pjdlog.c (the LOOK HERE's are my message editing) : ... #include sys/cdefs.h __FBSDID($FreeBSD: head/lib/libpjdlog/pjdlog.c 258791 2013-12-01 09:41:06Z pjd $); #include sys/types.h #include sys/socket.h #include sys/un.h #include netinet/in.h #include arpa/inet.h #include assert.h #include errno.h #include libutil.h #include limits.h #include printf.h /// LOOK HERE #include stdarg.h /// LOOK HERE for stdarg.h vs. printf.h order #include stdint.h #include stdio.h #include stdlib.h #include string.h #include syslog.h #include unistd.h #ifdef notyet #include robustio.h #endif #include pjdlog.h Context details: make -j 8 \ WITHOUT_CLANG_BOOTSTRAP= WITHOUT_CLANG= WITHOUT_CLANG_IS_CC= \ WITHOUT_LLDB= \ WITH_GCC_BOOTSTRAP= WITH_GCC= WITHOUT_GNUCXX= \ WITH_BOOT= WITH_LIB32= \ buildworld buildkernel \ KERNCONF=GENERIC64vtsc-NODEBUG \ TARGET=powerpc TARGET_ARCH=powerpc64 # more /etc/src.conf NO_WERROR= WITH_LIBCPLUSPLUS= # # # For trying gcc5... # CC=/usr/local/bin/gcc5 CXX=/usr/local/bin/g++5 CPP=/usr/local/bin/cpp5 AS=/usr/local/powerpc64-portbld-freebsd11.0/bin/as R=/usr/local/powerpc64-portbld-freebsd11.0/bin/ar LD=/usr/local/powerpc64-portbld-freebsd11.0/bin/ld NM=/usr/local/powerpc64-portbld-freebsd11.0/bin/nm OBJCOPY=/usr/local/powerpc64-portbld-freebsd11.0/bin/objcopy OBJDUMP=/usr/local/powerpc64-portbld-freebsd11.0/bin/objdump RANLIB=/usr/local/powerpc64-portbld-freebsd11.0/bin/ranlib SIZE=/usr/local/powerpc64-portbld-freebsd11.0/bin/size STRINGS=/usr/local/powerpc64-portbld-freebsd11.0/bin/strings # more /etc/make.conf WRKDIRPREFIX=/usr/obj/portswork #WITH_DEBUG= MALLOC_PRODUCTION= # svnlite info /usr/srcC/ Path: /usr/srcC Working Copy Root Path: /usr/srcC URL: https://svn0.us-west.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279514 Node Kind: directory Schedule: normal Last Changed Author: adrian Last Changed Rev: 279514 Last Changed Date: 2015-03-01 18:27:25 -0800 (Sun, 01 Mar 2015) # svnlite info /usr/ports/lang/gcc5 Path: /usr/ports/lang/gcc5 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5 Relative URL: ^/head/lang/gcc5 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: gerald Last Changed Rev: 380943 Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015) === Mark Millard markmi at dsl-only.net ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
