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

[Rafal Luzynski <digitalfreak@lingonborough.com>]

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

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

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