CONCLUSION (was Re: Fixincludes - some analysis)
gschafer at zip.com.au
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)
> #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
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
- 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
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 linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message
More information about the lfs-dev