Re: [RFC][PATCH v4 06/11] Provide backward compatibility for strftime family (bug 10871).

[Rical Jasan <ricaljasan@pacific.net>]

On 11/17/2016 03:18 AM, Rafal Luzynski wrote:
> Thank you for your reply, Rical.  I hope it moves us forward.
> 
> Please see more comments below:
> 
> 16.11.2016 14:05 Rical Jasan <ricaljasan@pacific.net> wrote:
>> [...]
>> As I understand it:
>>
>> 1. the standard doesn't say %B/MON_ should be genitive or nominative
>> 2. the standard does say UB for %O'x', x not in the list
>> 3. the current glibc %B/MON_ returns nominative
>> 4. the BSD/POSIX (proposed) %OB/ALTMON_ returns nominative
> 
> That's true as long as you remember that "nominative" is actually
> a shortcut for "a form appropriate when formatting a month name
> standalone, without a day number" and "genitive" is actually
> a shortcut for "a form appropriate when formatting a month name
> in a full date context, with a day number".

Right.  I was sticking with the much-easier-to-type version.

#define nominative ...

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

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.

>> So your patch is changing the behaviour of the format specifier %B in a
>> way allowable by the standard, and it adds a non-standard extension %OB
>> which the standard explicitly states is undefined, but not disallowed.
>> Additionally, binaries built against pre-%OB glibc running on post-%OB
>> glibc will still have the old behaviour.
> 
> True, backward compatibility for existing binaries is retained.
> There are of course concerns about existing sources which are
> recompiled without any change but as I noted before:
> 
> 1. If they are open source project we can reach them out and
>    help them adopt.
> 2. The cases where the change will be actually needed are probably
>    rare compared with the cases where a new behaviour of %B will
>    finally generate a correct form without any work on their side.
> 
>> I'm fine what that; I had a different version of this in my mind (see
>> below). Thank you for prompting me to give this more thought. You are
>> definitely between a rock and hard place. :)
>>
>> I think I should respond to Florian's objection [5] at this point.
>>
>> Florian,
>>
>> Were you opposed to the work of trying to make %B a little smarter? It
>> looks like Rafal abandoned that approach voluntarily, and opted to chase
>> the unification on the horizon when it was pointed out BSD and the POSIX
>> proposal were actually the same. [6]
>> [...]
> 
> When you refer to my earlier smart (heuristic) implementation of %B do
> you mean my attempt to implement an algorithm detecting if %B is in
> a context of full date (near a day number) or not?

Yes.

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

> Here I preserve your links:
> 
>>
>> [1]
>> http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html#tag_07_03_05
>> [2] http://pubs.opengroup.org/onlinepubs/009695399/functions/strftime.html
>> [3] https://sourceware.org/bugzilla/show_bug.cgi?id=10871
>> [4] http://austingroupbugs.net/view.php?id=258
>> [5] https://sourceware.org/ml/libc-alpha/2016-11/msg00322.html
>> [6] https://sourceware.org/bugzilla/show_bug.cgi?id=10871#c40
> 
> Regards,
> 
> Rafal

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