From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74399 invoked by alias); 1 Jun 2016 10:42:35 -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 74385 invoked by uid 89); 1 Jun 2016 10:42:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=H*r:508, remains, 10871, 29032016 X-HELO: micros1.altlinux.org Date: Wed, 01 Jun 2016 10:42:00 -0000 From: "Dmitry V. Levin" To: libc-alpha@sourceware.org Subject: Re: [RFC][PATCH v2 3/6] Implement the %OB specifier - alternative month names (bug 10871) Message-ID: <20160601104220.GA1077@altlinux.org> Mail-Followup-To: 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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline In-Reply-To: <666336576.426212.9ea90152-1d54-4eec-8ffa-81bfd328d92b.open-xchange@poczta.nazwa.pl> X-SW-Source: 2016-06/txt/msg00009.txt.bz2 --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 1184 On Wed, Mar 30, 2016 at 01:31:21AM +0200, Rafal Luzynski wrote: > 29.03.2016 16:31 "Dmitry V. Levin" wrote: > > On Fri, Mar 25, 2016 at 01:55:13AM +0100, Rafal Luzynski wrote: > > [...] > > > This means that all applications using %B to retrieve the month > > > name standalone should use %OB from now. > > > > Such applications as cal(1) would not be able to print month names > > properly in a way that would work with different glibc versions. > > Looks like this is a change incompatible in both ways. >=20 > Yes, that's exactly what will happen. Such applications must be > updated. They must start using strftime("%OB") and nl_langinfo(ALTMON_...= ). > They must either detect the glibc version at runtime and choose > the correct format specifier or require the minimum glibc version > at build time. I'm willing to contact the upstream developers and > provide the instructions how to change their applications. In glibc, we don't make changes this way. If an incompatible ABI change is introduced, the old ABI remains for compatibility with software linked with it. With regards to runtime checks, could you give an example of such a check? --=20 ldv --HcAYCG3uE/tztfnV Content-Type: application/pgp-signature Content-Disposition: inline Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJXTrwMAAoJEAVFT+BVnCUILUAP/3jnQcRSLlu1rv4PO+A+GCXX eMDi/a4/Sth2pJcew68pRgEJDB5zjH6ZTsPIj1wDaTsnSz8NJeetcyjzxuzxJagJ 6dOJ7WyKhFLX4h9JKsU75wvnsrubKG0jWY9Jhw4vLz7v6XGUf5dSh1VUmNpinh+I lMozfxgQozF6SRR4NDALi+tGGt8X1O+BG+oZ4YI/sazC+YY6GqzFT9WRilL0Cvb9 xCncxUMQa5Fi2I+iTOLj8RdvoKOZ+8BapYBFGZqkT1BomroavsGD1no35krdCx24 rsIVL/3LbjQho90McAS4SAfi/qpl7TK1gKW0cyzNbrBhqTCfOOSpnZJ0LC1oOHbf VxRZdDYW3akDWp1Jkj8krxn+fsHdQf6qvL+2yN5NWXrcgR81xrDGF3x5m+FNFR1l sT5fbCp2X/t4ya8CKUKMsw0B+snP+IhO8OKxdnbKQE98DHLPDZdES5JAyd5nuqPL EOY30fop5KgRPCytjVg43ekhO5OYk57BA673FYeqa8rpREG4KqMBPg0relffDXIu PYprLN4iPByRu8JHWQODfuUUVUhKkKL/M/Xz15amXBSWVb12mrBjBxNNyj86BpnM lS2uYbJqvy3sSi7JyWVZx2wLgGws5P0m07tC0KBHdWyjuWezlZ9LeROh60oZ50ub 3NrXBJ71a8hQX6ubaFZa =mixO -----END PGP SIGNATURE----- --HcAYCG3uE/tztfnV--