Date: Thu, 16 Oct 2014 03:53:33 +0200 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: Re: Constants to decode __ctype_b_loc() table * Rich Felker <dalias@...c.org> [2014-10-15 20:58:43 -0400]: > On Wed, Oct 15, 2014 at 10:19:46PM +0300, Sergey Dmitrouk wrote: > > 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. > i think the c++ std lib has a hard time implementing that efficiently (but it should be their problem not ours) it has to parse istreams in terms of ctype<> and there are inefficient apis like ctype<C>::is(const C*,const C*,mask*) which has to calculate the ctype mask for each char in a substring (so calling all is* c apis for each char..) > > 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. > well at least one standard specifies __ctype_b_loc http://refspecs.linux-foundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/baselib---ctype-b-loc.html but it does not specify the bitrepresentation (which is part of the abi) so it is useless i think this symbol has to be provided by glibc forever because of abi compat and the meaning of the flags cannot be changed however the glibc internal ctype implementation may change in the future including the undocumented flags/masks in glibc ctype.h so relying on those in any way is wrong
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.