Patch for newlib/libc/time

[Richard Earnshaw]

On Wed, 2011-06-01 at 11:23 -0400, Howland Craig D (Craig) wrote:
> I suggest that this is not the best way to handle this.  A drawback to
> this
> approach is that someone that is using floating-point-capable versions
> of
> print and scan would be stuck with a larger build because the
> integer-only
> routines get linked as supporting routines.  Wouldn't this be better as
> a library build option?  (Isn't there one already?)
>  
> Craig

You are talking about adding about a 150 bytes in the case where you get
both printf and iprintf, whereas the saving by not pulling in the
floating point code is several kb (dtoa is 6k alone).

Now maybe we could make the linker smart enough to know that printf
provides a superset of iprintf's functionality and that if we need both,
then printf can do the job of both.  That would be even smarter...

R.

> 
> -----Original Message-----
> From: newlib-owner@sourceware.org [mailto:newlib-owner@sourceware.org]
> On Behalf Of Philip Munts
> Sent: Monday, May 30, 2011 3:48 AM
> To: newlib@sources.redhat.com
> Subject: Patch for newlib/libc/time
> 
> Here is a patch to change xprintf() to xiprintf() and sscanf() to
> siscanf() in all of the source files in newlib/libc/time.  The rationale
> for this is to prevent linking floating point libraries in (at least)
> bare machine ARM target programs that call time functions like ctime().
> 
> There are other places in newlib this can be done safely, but this is a
> much as I am brave enough to submit for now.
> 
> Phil