From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6003 invoked by alias); 14 May 2013 17:02:36 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 5913 invoked by uid 48); 14 May 2013 17:02:27 -0000 From: "bugdal at aerifal dot cx" To: glibc-bugs@sourceware.org Subject: [Bug libc/15459] RFE: Add |localeconv_l()| to allow porting of FreeBSD/OSX applications... Date: Tue, 14 May 2013 17:02:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: bugdal at aerifal dot cx X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 X-SW-Source: 2013-05/txt/msg00103.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=15459 --- Comment #4 from Rich Felker 2013-05-14 17:02:26 UTC --- By harmful, I meant harmful to portability and/or application simplicity. If there's already a simple, portable way to do something that doesn't have excessive cost, adding a second way to do it means an application will take one of three paths: 1. Using the portable way and ignoring the availability of the non-portable one. 2. Adding configure checks and #ifdefs to use the new way optionally. 3. Using the new non-portable way unconditionally. Of these, I would consider option 1 the best for applications, since it minimizes complexity and maximizes compatibility. Option 2 risks bitrot in the code path that's not taken on the developers' systems. Option 3 means the program can only be used on BSD and GNU systems. Now if GNU is the only major system lacking this interface, or if other vendors are equally interested and willing to add it, then a path towards standardization, with applications using option 2 above and gradually phasing out the old option as implementations adopt the new interface(s), would be very reasonable. Actually glibc and BSD already have a number of *_l functions outside the ones standardized in POSIX 2008, so if this is the approach you want to take, it would be good to see if the committee is opposed to adding them all in Issue 8, and if not, doing the work to get them added (which basically amounts to writing the proposed text for the standard). -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.