From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3524 invoked by alias); 1 Jun 2016 23:54:29 -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 3502 invoked by uid 89); 1 Jun 2016 23:54:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=H*r:10.252.0, H*M:poczta, H*UA:Open-Xchange, H*x:Open-Xchange X-HELO: aev204.rev.netart.pl Date: Wed, 01 Jun 2016 23:54:00 -0000 From: Rafal Luzynski Reply-To: Rafal Luzynski To: libc-alpha@sourceware.org, Paul Eggert Message-ID: <480412909.686000.92369107-bdae-4a8b-b71f-99b919bc0cf0.open-xchange@poczta.nazwa.pl> In-Reply-To: <37aa7442-e282-a3bd-a7ce-6e06aed9172a@cs.ucla.edu> 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> <37aa7442-e282-a3bd-a7ce-6e06aed9172a@cs.ucla.edu> Subject: Re: [RFC][PATCH v2 3/6] Implement the %OB specifier - alternative month names (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-06/txt/msg00020.txt.bz2 2.06.2016 00:20 Paul Eggert wrote: > > [...] 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. Aaah, that's it! I did not know such a feature exists. So AFAIU this means that an executable provides to glibc some info what glibc version it was originally compiled with and if glibc is newer it is still able to provide the old behavior for old executables. Sounds nice, I will have to read more about it. (Any hints, links etc. are welcome.) > 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. What if a programmer, for example an author of cal(1), just rebuilds the unmodified source while it should be modified? Is there a way to tell them they should at least verify their source code? Anyway, I understand that I have to provide the old behavior for old executables. You're welcome to provide feedback about other issues. Regards, Rafal