[cfe-dev] [libc++] FYI: FreeBSD libc++ status

[Howard Hinnant]

On Jul 17, 2013, at 4:14 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:

> For anyone who's interested, I've imported a recent libc++ / libcxxrt into FreeBSD and Dimirty has merged it into the 9.2 release branch, so it should be showing up in the next release (Real Soon Now).  This will be the first FreeBSD release to ship libc++ in the default install (it was in the tree for 9.1 but required users to build from source).  The remaining test failures were as follows:
> 
>> /root/libc++/test/localization/locale.categories/category.ctype/locale.ctype.byname/tolower_many.pass.cpp failed at run time
>> /root/libc++/test/localization/locale.categories/category.ctype/locale.ctype.byname/toupper_1.pass.cpp failed at run time
>> /root/libc++/test/localization/locale.categories/category.ctype/locale.ctype.byname/toupper_many.pass.cpp failed at run time
> 
> I exchanged some emails with Howard about the tolower / toupper tests, but I don't fully understand what the correct behaviour is.  I suspect it may be due to differing interpretations of what a wchar_t contains.
> 
>> /root/libc++/test/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_fr_FR.pass.cpp failed at run time
>> /root/libc++/test/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_ru_RU.pass.cpp failed at run time
>> /root/libc++/test/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_fr_FR.pass.cpp failed at run time
>> /root/libc++/test/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_ru_RU.pass.cpp failed at run time
> 
> These all seem to fail with the facet::get() call.  I need to check what's going on there: the locale code does a lot of redundant creation of locale_ts for the facets, but I'd expect that to result in fewer bugs (just less performance) as it's more defensive than it needs to be.  
> 
> For these in particular, some C test cases from someone who understands the <locale> code would help me determine whether the bug is in libc++ or our libc (I'm quite familiar with the locale code in our libc, so I definitely wouldn't rule it out as a source of bugs).
> 
>> /root/libc++/test/localization/locale.categories/category.monetary/locale.moneypunct.byname/curr_symbol.pass.cpp failed at run time
> 
> This one fails because we return " Eu" as the currency symbol for France, which is probably a legacy thing from before applications were expected to understand UTF-8.
> 
>> /root/libc++/test/localization/locale.categories/category.monetary/locale.moneypunct.byname/grouping.pass.cpp failed at run time
>> /root/libc++/test/localization/locale.categories/category.monetary/locale.moneypunct.byname/neg_format.pass.cpp failed at run time
>> /root/libc++/test/localization/locale.categories/category.monetary/locale.moneypunct.byname/pos_format.pass.cpp failed at run time
> 
> These also seem to be due to differing locale data between FreeBSD and OS X.  I need to spend some time to work out which is correct: previous explorations indicated that OS X was shipping with a very old set of locale data (e.g. using the Soviet era currency symbol for the Russian Ruble), but some other differences have been bugs in the FreeBSD locale data.
> 
>> /root/libc++/test/re/re.traits/translate_nocase.pass.cpp failed at run time
> 
> This seems to be testing exactly the same thing as one of the toupper / tolower tests.  
> 
>> /root/libc++/test/strings/string.conversions/stof.pass.cpp failed at run time
> 
> This one is failing because std::stof(L"  - 8", &idx) is not throwing an exception.  It sets idx to 2, so I suspect here a bug in the conversion of L"  - 8" to a std::wstring.  Again, they may be related to some difference between clang, libc++ and FreeBSD libc over what a wchar_t contains.  I need to investigate this a bit more.
> 
> 
>> numerics/complex.number/complex.transcendentals/cos.pass.cpp failed to compile 
>> numerics/complex.number/complex.transcendentals/cosh.pass.cpp failed to compile 
>> numerics/complex.number/complex.transcendentals/sin.pass.cpp failed to compile 
>> numerics/complex.number/complex.transcendentals/sinh.pass.cpp failed to compile 
>> numerics/complex.number/complex.transcendentals/tan.pass.cpp failed to compile 
>> numerics/complex.number/complex.transcendentals/tanh.pass.cpp failed to compile 
> 
> 
> These functions are missing from our libm, so math.h omits them and they don't work.  Hopefully we'll have implementations of these for 10.0.
> 
>> strings/c.strings/cuchar.pass.cpp failed to compile 
>> strings/c.strings/version_cuchar.pass.cpp failed to compile 
> 
> These fail because, although FreeBSD has a <uchar.h>, libc++ lacks <uchar>
> 
> All in all, a pretty good set of results.  Almost all of the bugs are in localisation, and if people actually care about localisation I'd expect them to use ICU and not STL.  Once libc++ gets a <uchar> and FreeBSD libm gets the remaining C99 functions, we'll be in a very happy place.  The wchar interpretation issue concerns me somewhat, and I'll have to spend a little bit of time investigating it.

Thanks for this most informative update David.

I've wondered if libc++'s locale ought to be built on ICU instead of xlocale.  I don't know the answer to that question.

I've hesitated in adding <cuchar> because I can't test it.  However if you can add and test it, that would be a welcome addition.

Howard