Re: 11.0-CURRENT -r276514: lib/libpjdlog/pjdlog.c has <stdarg.h> after <printf.h>

From: Dimitry Andric <dim_at_FreeBSD.org>
Date: Sun, 22 Mar 2015 13:14:54 +0100
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 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


Received on Sun Mar 22 2015 - 11:15:14 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:56 UTC