Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 20 Nov 2011 15:03:09 +0100
From:      Jilles Tjoelker <jilles@stack.nl>
To:        David Chisnall <theraven@theravensnest.org>
Cc:        hackers@freebsd.org
Subject:   Re: xlocale patch
Message-ID:  <20111120140308.GA97965@stack.nl>
In-Reply-To: <C57AA994-0CB1-4875-8DB4-7D728B3E62AB@theravensnest.org>
References:  <DCAF3E3D-B2E1-40EF-B654-23625A17C3F1@theravensnest.org> <20110919172214.GJ33993@hoeg.nl> <3A86EAEA-1861-43A6-95DC-FC700BE0E507@theravensnest.org> <C57AA994-0CB1-4875-8DB4-7D728B3E62AB@theravensnest.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 21, 2011 at 08:28:54PM +0100, David Chisnall wrote:
> And here's an updated version of the patch.  I've fixed some other
> bugs, including where wcstod() and wcstodl() in trunk return the wrong
> value for any input string starting with spaces, wchar.h's violation
> of POSIX by not declaring FILE, and a few C++ incompatibilities in
> other headers (e.g. putchar being a macro, which breaks things like
> std::putchar(foo)).  All of my libcxxrt and libc++ changes have now
> been pushed upstream, so this should now be repeatable.  
> 
> The libunwind port still has an irritating bug in the header, where
> the extern "C" {} block ends with a semicolon, which causes it to be
> rejected in any C++ program, but with that fixed you can compile
> libcxxrt (I used cmake .. -DCMAKE_CXX_FLAGS="-I/usr/local/include
> -nostdlib -g" - hopefully I'll work out how to make CMake add these
> flags automatically soon...).  Libc++ should build out of the box with
> cmake.

I think it is unfortunate that <xlocale.h> depends on #include order; we
should be moving away from such ordering dependencies, not adding more.
POSIX does not have such dependencies so if they add all these new _l
functions, they will most likely do it differently.

POSIX.1-2008 has some of the _l functions but adds them to the plain
header; for example isalnum_l() is in <ctype.h> like isalnum(),
nl_langinfo_l() is in <langinfo.h> like nl_langinfo() and strcasecmp_l()
is in <strings.h> like strcasecmp(). This appears more sensible to me.
The <xlocale.h> header can then be an empty file.

-- 
Jilles Tjoelker



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111120140308.GA97965>