From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111284 invoked by alias); 1 Jun 2016 22:20:05 -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 111267 invoked by uid 89); 1 Jun 2016 22:20:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=month X-HELO: zimbra.cs.ucla.edu Subject: Re: [RFC][PATCH v2 3/6] Implement the %OB specifier - alternative month names (bug 10871) To: Rafal Luzynski , libc-alpha@sourceware.org References: <1155243857.420233.60a90901-4334-4cea-aa99-f76884316a10.open-xchange@poczta.nazwa.pl> <20160329143132.GA28928@altlinux.org> <666336576.426212.9ea90152-1d54-4eec-8ffa-81bfd328d92b.open-xchange@poczta.nazwa.pl> <20160601104220.GA1077@altlinux.org> <323322572.685262.92369107-bdae-4a8b-b71f-99b919bc0cf0.open-xchange@poczta.nazwa.pl> From: Paul Eggert Message-ID: <37aa7442-e282-a3bd-a7ce-6e06aed9172a@cs.ucla.edu> Date: Wed, 01 Jun 2016 22:20:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <323322572.685262.92369107-bdae-4a8b-b71f-99b919bc0cf0.open-xchange@poczta.nazwa.pl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-06/txt/msg00019.txt.bz2 On 06/01/2016 02:51 PM, Rafal Luzynski wrote: > I'm afraid that providing full backward compatibility is impossible. > If an application calls strftime("%B",...) or nl_langinfo(MON_...) > we have no way to tell if this particular application actually > meant "%OB" and ALTMON_... or it is indeed correct for it to call > "%B" and MON_. Of course glibc cannot tell for sure; it is not an oracle. However, if glibc uses the old behavior when the application links to the old strftime, and the new behavior when the application links to the new strftime, then old executables will have the same old behavior even when linked to new glibc, which was Dmitry's point. Even if the new behavior is standardized and is more likely to be what the user wants, there will almost surely be cases where the old behavior is preferable (if only to make regression tests pass :-), and the natural way to tell programmers about this is to say that old programs get the old behavior and new programs get the new one.