Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 16 Oct 2014 03:53:33 +0200
From: Szabolcs Nagy <>
Subject: Re: Constants to decode __ctype_b_loc() table

* Rich Felker <> [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

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.