Re: [PATCH] Improve the width of alternate representation for year in strftime [BZ #23758]

[TAMUKI Shoichi <tamuki at linet dot gr dot jp>]

Hello Florian,

Thank you for your review.

From: Florian Weimer <fweimer@redhat.com>
Subject: Re: [PATCH] Improve the width of alternate representation for year in strftime [BZ #23758]
Date: Tue, 23 Oct 2018 14:54:04 +0200

> Thanks for this suggestion.  To you have a copyright assignment for
> glibc on file?

Currently in progress.  I sent the information for request-assign.future
to assign@gnu.org over ten days ago.

> It looks like that there are two changes (plus some formatting cleanups)
> in this patch: the change in padding:
> 
> > -		  DO_NUMBER (1, (era->offset
> > +		  DO_NUMBER (2, (era->offset
> >  				 + delta * era->absolute_direction));
> 
> and adding a way to override the padding, when %EY is exanded using
> locale data, rewriting the %Ey contained in the format string.

Yes, that's right.

> I think the second part should be handled differently, by not rewriting
> the format string, and rather adding strftime arguments (possibly in a
> struct) to set the default padding.
> 
> This should also avoid the need for new memory allocations.

Certainly.  I also want to avoid dynamic memory allocation as much as
possible.  To add strftime arguments, which is not the prepared format
string (era_format in locale data) but the modified string (rewriting
the %Ey), anoher allocated separate memory is required.

An alternative plan will be to allocate memory beforehand statically.
In that case, we have to decide the size to be assumed.

Currently, there are 3 locales which use era format.  The maximum
length of era format (including null) is 16 bytes in wchar_t for now.

tamuki@seadog:~/glibc/localedata/locales$ grep -A10 "^\<era\>" *
ja_JP:era	"+:2:1990//01//01:+*:<U5E73><U6210>:%EC%Ey<U5E74>";/
ja_JP-	"+:1:1989//01//08:1989//12//31:<U5E73><U6210>:%EC<U5143><U5E74>";/
ja_JP-	"+:2:1927//01//01:1989//01//07:<U662D><U548C>:%EC%Ey<U5E74>";/
ja_JP-	"+:1:1926//12//25:1926//12//31:<U662D><U548C>:%EC<U5143><U5E74>";/
ja_JP-	"+:2:1913//01//01:1926//12//24:<U5927><U6B63>:%EC%Ey<U5E74>";/
ja_JP-	"+:2:1912//07//30:1912//12//31:<U5927><U6B63>:%EC<U5143><U5E74>";/
ja_JP-	"+:6:1873//01//01:1912//07//29:<U660E><U6CBB>:%EC%Ey<U5E74>";/
ja_JP-	"+:1:0001//01//01:1872//12//31:<U897F><U66A6>:%EC%Ey<U5E74>";/
ja_JP-	"+:1:-0001//12//31:-*:<U7D00><U5143><U524D>:%EC%Ey<U5E74>"
ja_JP-
ja_JP-era_d_fmt	"%EY%m<U6708>%d<U65E5>"
--
lo_LA:era     "+:1:-543//01//01:+*:<U0E9E>.<U0EAA>.:%EC %Ey"
lo_LA-era_d_fmt       "%e %b %Ey"
lo_LA-era_t_fmt       "%H.%M.%S <U0E99>."
lo_LA-era_d_t_fmt     "<U0EA7><U0EB1><U0E99>%A<U0E97><U0EB5><U0EC8> %e %B %EC %Ey, %H.%M.%S <U0E99>."
lo_LA-% Appropriate date representation (date(1))
lo_LA-date_fmt       "%a %e %b %Ey %H:%M:%S %Z"
lo_LA-week 7;19971130;1
lo_LA-END LC_TIME
lo_LA-
lo_LA-LC_MESSAGES
lo_LA-
--
th_TH:era     "+:1:-543//01//01:+*:<U0E1E>.<U0E28>.:%EC %Ey"
th_TH-era_d_fmt       "%e %b %Ey"
th_TH-era_t_fmt       "%H.%M.%S <U0E19>."
th_TH-era_d_t_fmt     "<U0E27><U0E31><U0E19>%A<U0E17><U0E35><U0E48> %e %B %EC %Ey, %H.%M.%S <U0E19>."
th_TH-% Appropriate date representation (date(1))
th_TH-date_fmt       "%a %e %b %Ey %H:%M:%S %Z"
th_TH-week 7;19971130;1
th_TH-END LC_TIME
th_TH-
th_TH-LC_MESSAGES
th_TH-

So, I think we should prepare an array of 32 bytes with a margin.
What do you think.

Regards,
TAMUKI Shoichi