From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6335 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Constants to decode __ctype_b_loc() table Date: Wed, 15 Oct 2014 20:58:43 -0400 Message-ID: <20141016005842.GT32028@brightrain.aerifal.cx> References: <20141015104142.GA2186@zx-spectrum.accesssoftek.com> <20141015113207.GF4874@port70.net> <20141015120531.GA5017@zx-spectrum.accesssoftek.com> <20141015165136.GS32028@brightrain.aerifal.cx> <20141015191946.GB1552@zx-spectrum.accesssoftek.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1413421143 32254 80.91.229.3 (16 Oct 2014 00:59:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 16 Oct 2014 00:59:03 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6348-gllmg-musl=m.gmane.org@lists.openwall.com Thu Oct 16 02:58:56 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XeZP6-0001PN-Fy for gllmg-musl@plane.gmane.org; Thu, 16 Oct 2014 02:58:56 +0200 Original-Received: (qmail 5440 invoked by uid 550); 16 Oct 2014 00:58:55 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 5432 invoked from network); 16 Oct 2014 00:58:55 -0000 Content-Disposition: inline In-Reply-To: <20141015191946.GB1552@zx-spectrum.accesssoftek.com> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6335 Archived-At: On Wed, Oct 15, 2014 at 10:19:46PM +0300, Sergey Dmitrouk wrote: > On Wed, Oct 15, 2014 at 09:51:36AM -0700, Rich Felker wrote: > > Basically, libstdc++ should be using ... > > Well, I'm talking about libc++, not libstdc++. libc++ doesn't have > such headers and all is kept in one big locale.cpp. It's easy to > hard-wire these constants for generic case, but is it really correct > solution? No, using those interfaces AT ALL is incorrect. They are not a public API but glibc implementation internals. The correct way to implement the locale functionality in C++ is to call the ctype.h/wctype.h functions, not using glibc implementation internals. > It doesn't seem to be standardized. Values in > os/generic/ctype_base.h differ from those one can find in C++ standard. The standard has no such thing. These are implementation details. > There is even a comment: > > // Default information, may not be appropriate for specific host. > > My point is that musl can have these masks defined to arbitrary values > and there is currently no way for a client to know exact values. It > just happens to work, no guarantees. No, the generic implementation does not use the glibc internals at all. Since the rest of libstdc++'s locale support is written based on the glibc internals, the generic implementation just provides an interface that looks like the glibc one using standard functions. > The question is whether you want to keep it in this somewhat incomplete > state, when particular values of constants are assumed and undocumented (e.g. > if this is really just for libstdc++, which can live without constants). No, the question is whether we want to provide glibc internals as a public API, and the answer is no. Rich