This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] strftime: Add POSIX flags, width, and handling for E and O modifier


On Feb 24 15:52, Jeff Johnston wrote:
> On 24/02/10 03:24 PM, Corinna Vinschen wrote:
> >On Feb 24 15:00, Howland Craig D (Craig) wrote:
> >>The E and O modifiers are C99, also (not just POSIX extensions).
> >>So if that were to be gated, it would want to be something like
> >>#if defined(USE_LOCALE)
> >
> >We don't have that define at all.  If I was going to introduce it,
> >where else should it go?  That's a bit generic, isn't it?
> >
> 
> You could follow the lead of the _WANT_IO_C99_FORMATS flag used in
> vfprintf.c and possibly introduce a _WANT_C99_STRFTIME_FORMATS.  We
> could also add a generic _USE_C99 or _WANT_C99 flag that turns on
> all C99 optional features at once.

Sounds good to me.  We should just use a more generic name like
_WANT_C99_TIME_FORMATS.  The reason is, that strptime needs that
extension as well, so STRFTIME would be misleading.

However, _WANT_IO_C99_FORMATS is a configure time option
(--enable-newlib-io-c99-formats).  Setting _WANT_C99 in sys/config.h
would override the configure time settings so we should avoid that.

So the question is this.  Does it make sense to add another configure
option --enable-newlib-strftime-c99-formats?  If yes, ok, if not, I
would just add another option to sys/config.h and not call it _WANT_foo
but just, say , _C99_TIME_FORMATS.

I'm not so sure anymore about using the __POSIX_2008_STRFTIME__ flag for
the padding and width modifiers at all, though.
The code difference between enabling and disabling them isn't that much.
Without optimization, and without debug symbols, the size of the i386
object file grows by 5K in case
of the E and O modifier handling.  Disabling and enabling padding and
width only changes the size by less than 500 bytes.

If you put that into relation to a file size of 9K for the strftime
function without E/O handling and 15K with, it seems to make not a lot
of sense to conditionalize that part of the code.  The strftime function
is already in it's basic form not really feasible for very small
targets.  I would opt for handling padding and width unconditionally.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]