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

Jeff Johnston jjohnstn@redhat.com
Thu Feb 25 17:47:00 GMT 2010


On 25/02/10 05:17 AM, Corinna Vinschen wrote:
> 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.
>

There is no problem with adding a WANT flag and not adding a configure 
option.  Assume platforms will want it on or off by default and we can 
deal with future requests as they come.  Most platforms will not care as 
they aren't using the new feature currently.  Those that are 
standard-conscious will turn it on regardless.

> 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.
>

Ok.  I suggest for now, add a comment around the code so if we want to 
add a flag later, it will be easy.  Something simple like: /* POSIX 2008 
feature */
>
> Corinna
>



More information about the Newlib mailing list