Fixincludes - some analysis

Matthias Benkmann matthias at
Mon Jan 27 08:29:24 PST 2003

On Mon, 27 Jan 2003 19:20:32 +1100 Greg Schafer <gschafer at>

> For anyone interested, here is how I tested:-
> 1) in the cwd create a dir called fixed and copy in the fixed stdio.h
> 2) in the cwd create a dir called notfixed and copy in the original
> stdio.h 3)
> cat > foo.c << "EOF"
> #define _GNU_SOURCE 1
> #include <stdio.h>
> int main()
> {
>   return 0;
> }

You might want to test an actual program that uses va_list such as (from
libc manual)

#include <stdio.h>
#include <stdarg.h>
void eprintf (const char *template, ...)
       va_list ap;
       extern char *program_invocation_short_name;
       fprintf (stderr, "%s: ", program_invocation_short_name);
       va_start (ap, template);
       vfprintf (stderr, template, ap);
       va_end (ap);

int main()
  char* filename="foobar"; 
  eprintf ("file `%s' does not exist\n", filename);
  return 0;

Does it work with fixed/unfixed and with/without <stdarg.h>?
> HOWEVER, if I add an #include <stdarg.h> just after the #include
> <stdio.h> the results change to:-
> fixed:
> typedef __builtin_va_list __gnuc_va_list;
> typedef __gnuc_va_list __not_va_list__;
> typedef __gnuc_va_list va_list;
> notfixed:
> typedef __builtin_va_list __gnuc_va_list;
> typedef __gnuc_va_list va_list;
> va_list gets typedef'd in both instances! Can you make a conclusion from
> that?

AFAIK, you're not supposed to use va_list without including stddef.h, so
it would seem that the fix is completely uneffective for properly written
programs (which may or may not be intentional). Does it depend on the
order? What happens if you swap the 2 includes? If this changes the
situation, my only conclusion is that whatever the fix does, it's broken.
The va_list type should not depend on the order in which headers are


Want to learn long division in ternary?
Contact me at ICQ 2101001122212.01/0.00002

Unsubscribe: send email to listar at
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list