[uClibc]Re: sudden data bloat

[Manuel Novoa III]

Miles,

On Sat, Mar 23, 2002 at 09:10:13AM +0900, Miles Bader wrote:
> All this makes me wonder if there's some way to automate the `only pull
> in float / error msgs / whatever if the user actually uses %g / %m / ?'
> 
> Since gcc already knows about printf formatting so it can check
> arguments, perhaps it could coaxed into generating symbol references
> for certain cases.

Does gcc 3.0 know about positional args?  2.96 doesn't seem to...
That would be a complication.

> E.g.:
> 
>     -- symbol ref --           -- meaning --
>    __printf_uses_float        Some call to `printf' uses %g or %f or ...
>    __fprintf_uses_float       Some call to `fprintf' uses %g or %f or ...
>    __printf_uses_emsgs        Some call to `printf' uses %m
>        etc.
>    __printf_uses_unknown      Some call to printf uses a non-constant fmt string
>        etc.
> 
> Then the printf core could use weak references for the various
> expensive bits, which would be pulled in by one or more of the above
> symbols.
> 
> So whad'ya think?  Does this seem like it would work?

Well, you couldn't rely on the format strings being placed literally in
the *printf calls themselves.  They could be function args or pulled
from a string table or built dynamicly by the app itself.  They could
even be user input... one reason given for the parse_printf_format()
function in glibc.  Of course, in the versions I tested, you can still
get glibc's printf to segfault with a format string that
parse_printf_format() accepts.  Try printf("%9999999999d\n", 1) with
glibc... it doesn't seem to trap the integer overflow.

I suppose gcc could catch floating point args in [^v]*printf, but
that wouldn't work for vfprintf.  And nothing but seeing the format
string itself would catch %m since it uses no args.  So I don't think
there's any real way in general for gcc to determine what support
is needed for printf.

> [Of course, maybe it's just not worth it, if real programs always end
> up using float anyway or something....]

One approach I had thought about was defining some preprocessor macros
in stdio.h that would expand to things like the functions/variables I used
in the helloworld example to disable the unwanted stuff.  You could
simply include those in one of your source files to disable what you
wanted.  Of course, if you're linking dynamicly this actually makes
things bigger.  

Another possibility would be to add some gcc wrapper options... say
--uclibc-printf-no-float and --uclibc-printf-no-mspec... to link in
the necessary disablers prior to libc.a in the staticly linked case.

I'm certainly open to other suggestions for finer-grained control than
just enabling/disabling things at library build time.

Manuel