Mike Frysinger wrote:
> > > --- a/lib/printf-parse.h
> > > +++ b/lib/printf-parse.h
> > > @@ -25,6 +25,9 @@
> > >
> > > #include "printf-args.h"
> > >
> > > +#ifdef HAVE_FEATURES_H
> > > +# include <features.h> /* for __GLIBC__ */
> > > +#endif
> > >
> > > /* Flags */
> > > #define FLAG_GROUP 1 /* ' flag */
> >
> > Why should this be needed? printf-args.h include <wchar.h> and,
> > <wchar.h> includes <features.h>. Admittedly this is thin ice, but in
> > general we know that every glibc header file includes <features.h>.
>
> except that every glibc header doesnt, and this current reliance on implicit
> inclusion fails on uClibc systems when wchar.h isnt provided.
Oh, you're talking about uClibc, not glibc! That's a different platform than
glibc.
- It has a very different FILE structure in <stdio.h>.
- It sometimes has no <wchar.h>, depending how it was configured.
- Its <features.h> file sometimes defines __GLIBC__ and sometimes doesn't,
depending whether __FORCE_NOGLIBC or __FORCE_GLIBC is defined.
- It doesn't have all the functions that glibc has.
gnulib needs to treat this differently than glibc platforms
1. because it's not glibc,
2. because you can't reliably test for the presence of __GLIBC__ on this
platform.
uClibc has two *printf implementations, again, depending on configuration
flags: one that does not support the 'I' flag and one that ignores it
("we don't currently support glibc's 'I' flag. We do accept it, but it is
currently ignored."). I don't think they will implement the 'I' flag
ever, since it's against the policy of small code, and people who want
decent internationalization use glibc anyway. Therefore we can just assume
that it doesn't support it.
I'll review all uses of __GLIBC__ in gnulib tomorrow.
Bruno
