Re: printf size requirement

[Jeff Johnston <jjohnstn at redhat dot com>]

Eric Blake wrote:
> Joel Sherrill <joel.sherrill <at> oarcorp.com> writes:
>
>   
> > > > + wide character support is in both and is about .75K
> > > >         
>
> It looks like vfprintf.c tries to minimize wide character support if configured 
> with --disable-newlib-mb, as evidenced by the use of _MB_CAPABLE.  
> Unfortunately, there are uses of _wcrtomb_r outside of _MB_CAPABLE blocks, 
> meaning that this was a half-baked disable.  Jeff, is it okay to apply this 
> patch, since the POSIX-mandated '%C', '%lc', '%S', and '%ls' are already 
> crippled in non-multibyte builds, in an effort to reduce code size there?
>
> patch1:
> 2007-04-24  Eric Blake  <ebb9@byu.net>
>
> 	* libc/stdio/vfprintf.c (_VFPRINTF_R): Avoid multibyte when not
> 	_MB_CAPABLE.
>
> Meanwhile, we could intentionally cripple the iprintf variants to not support 
> wide characters, in order to continue keeping iprintf lightweight.  OK to apply 
> this patch on top of the previous?
>
> patch2:
> 2007-04-24  Eric Blake  <ebb9@byu.net>
>
> 	* libc/stdio/vfprintf.c [INTEGER_ONLY]: Always avoid multibyte in
> 	iprintf.
>
>
>   
Yes to patch 1.  No to patch 2.  The iprintf function is not defined to 
be small; it is defined to be printf sans floating-point support.  Thus, 
you are changing the behavior unexpectedly for someone already using 
iprintf on a multibyte-enabled platform.  I have no problems with using 
alternate flags to achieve size reduction sets, but not this way.

-- Jeff J.
> > > > + printf version includes the "mprec" code, references
> > > >     
> > > >         
> > >   soft float, etc.
> > >       
>
> If I understand correctly, there is a configure-time decision as to whether 
> your platform defaults to hard or soft float; but yes, pulling in floating 
> point code is part of the printf bloat.
>
>   
> > > > + both include locale code
> > > >         
>
> printf currently needs locale in order to support the locale decimal 
> character.  But it seems like iprintf should not be sucking it in; I'm not 
> seeing where that is happening, since the only call to localeconf is protected 
> by FLOATING_POINT.
>
> This also points out another printf bug: localeconv() is not threadsafe, but 
> POSIX requires printf to be threadsafe, so using localeconv()->decimal_point 
> probably violates POSIX.  It certainly isn't reentrant, at any rate.  And if 
> newlib is truly hard-coded to the C locale, even this isn't necessary - we 
> could just use '.' and be done with it.
>
>   
> > >   --enable-newlib-io-pos-args enable printf-family positional arg support
> > >   
> > >       
> > I see the code that this disables but can't tell if this is disabling 
> > something OpenGroup
> > or POSIX expect to be present.
> >     
>
> C99 does not require it, but POSIX does.  It is what makes
> printf("%2$*1$d",width,value) work.  If all you care about is C99, then turn it 
> off, but unfortunately, it isn't the biggest source of bloat.
>
>   
> > >   --enable-newlib-mb        enable multibyte support
> > >   
> > >       
> > This looks like a feature which might be worth discussing disabling or 
> > possibly
> > adding as a multilib variant.  But it would double the number of 
> > libc.a's we ship
> > and with 11 targets and 70 libc.a's already, it doesn't sound appealing.
> >     
>
> If patch2 is applied, you will get lightweight iprintf without multilib.  But 
> if you do go with multilib, then even patch1 should help reduce size of the non-
> multibyte variant.
>
>