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: [RFC][PATCH v4 06/11] Provide backward compatibility for strftime family (bug 10871).


I'm sorry for this late reply.

18.11.2016 10:22 Rical Jasan <> wrote:
> On 11/17/2016 03:18 AM, Rafal Luzynski wrote:
> > As Florian correctly
> > pointed out in some languages (German, also English) a correct form
> > when formatting a full date is nominative. These languages should
> > not be forced to use genitive if their rules say not to use
> > genitive in that context.
> I believe you had pointed out that the genitive/alternate forms would
> need to be present in the locale data, and could be omitted for
> languages that didn't need them, yielding the correct results in practice.

Right, that's the point.  I'm glad I have explained this in an
understandable way.

> I'm not sure the problem can be appropriately addressed without a fully
> general solution, which makes how you deal with it something of a lynch
> pin in getting even the most minimal of fixes accepted. Trying to solve
> this issue is what puts you in standards and extensions land---and it
> does not look like travel is permitted there at this time. Extra care
> in designing the code to be easily modified no matter how the general
> solution winds up looking (whether %OB is standardized, glibc begins
> using their own extensions some day, etc.) is probably energy better spent.

I'm not sure if I understand this paragraph correctly.  Did you mean
that we can't introduce this change because it involves some specification
change?  Unfortunately, I'm afraid it's impossible to do it without
a specification change.  That's why I asked about a committee which is
powerful enough to introduce such a change.

Also, regarding the design of the code, I usually pay particular attention
to this.  If you think it can be improved I'll appreciate your comments.
However, I think that the specification questions are more important
at this moment because there is no reason to polish a code which will
be rejected for the specification reasons.

> [...]
> > Except realizing
> > that BSD and the POSIX proposal are actually the same there is another
> > argument against the smart algorithm. I think that I saw an implementation
> > in a date utility which scans the format string and then calls strftime()
> > for each format specifier separately. This way a smart implementation
> > would have no way to tell if %B is just after a day number (well, it could
> > maintain some internal state) and definitely no way to tell if the next
> > call after a current %B will also contain a day number.
> Just preserve the status quo in cases you can't be absolutely sure the
> alternate form is correct.
> I think another way to ask the question I posed to Florian, making it
> more general for everybody, and getting more to my point of trying to
> find a suitable compromise, is: can a solution that doesn't address the
> problem of cases in month names in full generality ever be found
> acceptable as a fix for this bug?
> By tucking some logic away behind %B that can return alternative month
> names in the proper context and otherwise just do the same thing it
> always did, we add code that may be construed as temporary, even if it
> winds up lasting over a decade waiting for some standard to fix the
> general issue, and I don't know how everybody feels about that. Some
> may want to avoid the possibility it ever gets grandfathered in due to
> longevity. "Dirty hack" was thrown around a bit in the bug discussion.
> There is also the ever-present reality of imposing a maintenance burden
> on others. A narrowly-scoped, smaller fix might assuage some of those
> fears.

If you prefer my older heuristic solution the patches are somewhere
around so they can always be retrieved, reworked, and applied.
However, I can see a problem here.  This heuristic algorithm would
work correctly in most cases and incorrectly in few cases.  Yes, one
can say the same about a deterministic algorithm implementing %OB
explicitly.  But in case of a deterministic algorithm the problem
can be fixed changing the application source code.  In case of
the heuristic algorithm there is no switch to tell "yes, I really
want this nominative (genitive) case here."

Particularly, it will not work correctly in the date command line
utility which I perceive as the most versatile testing tool for
the dates format.

I have discussed probably all possible solutions here. [1]

It's probably not a correct solution but thinking hard I've found
another one:

1. Switch nl_langinfo(MON_x) and strftime("%B"...) to generate
   the genitive form (where two forms are needed) always.  Almost
   no coding required, just put the genitive forms into the locale
   data and say this is what should have always been there.
2. Don't implement the "%OB" format specifier.  (See below why).
3. However, do implement nl_langinfo(ALTMON_x) and let it return
   the nominative month names where needed.  This is simpler than
4. nl_langinfo(ALTMON_x) would be the only way to retrieve the
   month name in a nominative case.  It will be impossible to
   do it with strftime().  Sorry, standalone is standalone, not

Please take it as brainstorming and/or a kinda proof that every
other solution is even less acceptable. :-)

> [...]
> I sincerely hope we can find a direction that is acceptable to the
> maintainers that fixes the blatant problem while managing to avoid
> becoming a standardization issue. I'd hate to see this bug be solved as
> WONTFIXYET after all your work. :)
> Rical

Thank you for your support so far.  Ulrich Drepper said "You'll have
to provide a complete patch." [2] As far as I know Ulrich is no
longer around here but here is a complete patch, even if it needs
some rework to fit to glibc standards.  I'll appreciate if you
guys give more comments or even put some of your work into
finalizing it.

Best regards,



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