From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47861 invoked by alias); 17 Nov 2016 11:18:43 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 47833 invoked by uid 89); 17 Nov 2016 11:18:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=realizing, month, H*x:Mailer, H*UA:Mailer X-HELO: aev204.rev.netart.pl Date: Thu, 17 Nov 2016 11:18:00 -0000 From: Rafal Luzynski Reply-To: Rafal Luzynski To: libc-alpha , Florian Weimer , Rical Jasan Message-ID: <956759494.402156.1479381508919@poczta.nazwa.pl> In-Reply-To: <703fb2bf-bf30-841d-3bd9-23c32364edb5@pacific.net> References: <1326125332.562051.1478737983449@poczta.nazwa.pl> <76b198b7-a35e-cbaf-ee15-339a196acab2@pacific.net> <1063625629.140370.1479173885642@poczta.nazwa.pl> <703fb2bf-bf30-841d-3bd9-23c32364edb5@pacific.net> Subject: Re: [RFC][PATCH v4 06/11] Provide backward compatibility for strftime family (bug 10871). MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Originating-Client: com.openexchange.ox.gui.dhtml X-SW-Source: 2016-11/txt/msg00609.txt.bz2 Thank you for your reply, Rical. I hope it moves us forward. Please see more comments below: 16.11.2016 14:05 Rical Jasan 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