CONCLUSION (was Re: Fixincludes - some analysis)

Greg Schafer gschafer at
Mon Jan 27 23:48:09 PST 2003

On Mon, Jan 27, 2003 at 05:29:24PM +0100, Matthias Benkmann wrote:
> You might want to test an actual program that uses va_list such as (from
> libc manual)
> ---------------------temp.c--------------------
> #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>?

No. It fails to link if I don't include <stdarg.h>. Otherwise, it works
fine. Interestingly, it is a different error message when _GNU_SOURCE is

/tmp/cco60TrA.o(.text+0x32): In function `eprintf':
: undefined reference to `va_start'
/tmp/cco60TrA.o(.text+0x58): In function `eprintf':
: undefined reference to `va_end'
collect2: ld returned 1 exit status

msb.c: In function `eprintf':
msb.c:9: `va_list' undeclared (first use in this function)
msb.c:9: (Each undeclared identifier is reported only once
msb.c:9: for each function it appears in.)
msb.c:9: parse error before "ap"
msb.c:13: `ap' undeclared (first use in this function)

My simple grep's of the preprocessed source were the same as for my simple
(somewhat less useful) testcase.

> 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
> included.

Did you mean stdarg.h there? I think you did. Either way, the inclusion
order doesn't seem to change any results. So it seems Justin is correct when
he mentioned the standards and the necessity to include stdarg.h.

Above all, I can now safely conclude that the fixed stdio.h makes no


 - fixincludes uses heuristics to work out what headers to fix

 - due to the above, it's a bit of "hit & miss" affair as to actually which
   headers get fixed

 - often headers get bogus or irrelevant fixes and in some rare cases even
   erroneous fixes

 - fixincludes does not fix headers in /usr/local/include

 - if gcc gets reinstalled, a new run of fixincludes takes place which
   introduces all sorts of potential problems (witness recent openssl mess)
 - if headers need legitimate fixing, it is far better to send the fixes
   upstream and fix the problem at the source

 - fixincludes is much more useful when installing gcc on say some
   proprietary system where the system headers really do need fixing to work
   with a proper ANSI compiler

 - glibc developers seem to "not give a fuck" that some 3rd party program is
   modifying their beloved stdio.h

 - even senior gcc gurus do not understand the full wonders of fixincludes

 - seasoned LFS'ers who have taken the plunge and not installed the
   fixincluded headers n Ch 6 report no breakage

 - the current fixincludes as applied to a current CVS LFS do not make 1
   iota of difference to the end result according to the analysis within
   this thread

I think I have finally convinced myself that fixincludes is more trouble
than it's worth (in the context of LFS) and doesn't achieve anything useful
for us at all.

I recommend that we give it the big flick for Ch 6 and thus rid ourselves of
this strange and mysterious beast.

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