This is the mail archive of the mailing list for the glibc 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: [PATCH] Improve the width of alternate representation for year in strftime [BZ #23758]

Hello Florian,

Thank you for your review.

From: Florian Weimer <>
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 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-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
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

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

TAMUKI Shoichi

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