From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40153 invoked by alias); 16 Nov 2016 13:06:10 -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 39369 invoked by uid 89); 16 Nov 2016 13:06:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=rock, younger, compromise, lieu 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> From: Rical Jasan Message-ID: <703fb2bf-bf30-841d-3bd9-23c32364edb5@pacific.net> Date: Wed, 16 Nov 2016 13:06:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <1063625629.140370.1479173885642@poczta.nazwa.pl> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Null-Tag: 647d488be21b1a16c9cab732733b51f4 X-SW-Source: 2016-11/txt/msg00540.txt.bz2 On 11/14/2016 05:38 PM, Rafal Luzynski wrote: > Thank you, Rical for your feedback. It's valuable even if I don't > agree. I'm sorry if I'm repeating the same thing again I should apologize because I was not nearly as up on this bug as I thought I was. Thank you for the links; following the gnome/glib bug which referenced the glibc bug 10871 as "glibc developers are not interested in solving this on their level" had me paying closer attention to the history there (7 years...) and putting this thread in that context. 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 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. 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] I was originally opposed to the idea of making %B act differently in different contexts where it didn't before, but in light of the fact the implementation isn't restricted to a particular format/case, that does seem a reasonable compromise. The POSIX proposal is 6-1/2 years old now, barely younger than this bug, and we have someone who is interested in fixing it *now*, in a way that keeps us flexible for whatever happens with the standards, who-knows-when. We could avoid a new specifier extension (in lieu of standardization), and %B could be viewed as partially "fixed", in that it just might get it right more often than it already does. The bug is about returning the correct case, in a context we might be able to determine, not whether we should define our own standard for %B or an extension %OB. Could we avoid addressing the whole future standards issue by limiting the fix to making %B return genitive in cases where it can be sure it should, where the genitive is even available? Rical [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