Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 15 Oct 2014 22:07:12 -0400
From: Rich Felker <>
Subject: Re: Constants to decode __ctype_b_loc() table

On Thu, Oct 16, 2014 at 03:53:33AM +0200, Szabolcs Nagy wrote:
> * 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..)

This sounds like an inefficient API to use...

> > > 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

In the link you cited:

    "This interface is not in the source standard; it is only in the
    binary standard."


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.