From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4947 invoked by alias); 18 Nov 2016 09:22:49 -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 4930 invoked by uid 89); 18 Nov 2016 09:22:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=quo, yielding, construed, realizing X-HELO: mail.pacific.net Subject: Re: [RFC][PATCH v4 06/11] Provide backward compatibility for strftime family (bug 10871). To: Rafal Luzynski , libc-alpha , Florian Weimer 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> <956759494.402156.1479381508919@poczta.nazwa.pl> From: Rical Jasan Message-ID: Date: Fri, 18 Nov 2016 09:22:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <956759494.402156.1479381508919@poczta.nazwa.pl> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Null-Tag: 8bf0e2ba51c966dfaffd87bee1fed3af X-SW-Source: 2016-11/txt/msg00650.txt.bz2 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 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