[PATCH] [libcxx] Get categories.numeric and facet.numpunct localization tests passing on linux

[Eric Fiselier]

> This all looks OK to me, but I wonder - is there a *right* answer for these routines. If so, what is the answer we should be expecting?

@mclow.lists There might be a right answer for the NAN changes. Last I looked into this there was a change to support positive and negative NAN. I'll come back with a real answer tomorrow. However the separator and grouping test data seems to make more sense with GLIBC.

================
Comment at: test/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_long_double.pass.cpp:10722
@@ -10721,1 +10721,3 @@
     const my_facet f(1);
+
+#if !defined(__GLIBC__)
----------------
Dan Albert wrote:
> Marshall Clow wrote:
> > Are these values mandated by a standard somewhere - or are they just "implementation defined"?
> > 
> > 
> I had previously misread this part of the diff. This looks wrong to me now that I look closer (and with all the context). Specifically, [ul]nan4. That can't be right.
I think it follows 22.4.2.2.2. It seems weird but my reading of the standard does not make it incorrect.
I'll look into it some more. The rest of the cases seem reasonable though.

================
Comment at: test/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_long_double.pass.cpp:10722
@@ -10721,1 +10721,3 @@
     const my_facet f(1);
+
+#if !defined(__GLIBC__)
----------------
Eric Fiselier wrote:
> Dan Albert wrote:
> > Marshall Clow wrote:
> > > Are these values mandated by a standard somewhere - or are they just "implementation defined"?
> > > 
> > > 
> > I had previously misread this part of the diff. This looks wrong to me now that I look closer (and with all the context). Specifically, [ul]nan4. That can't be right.
> I think it follows 22.4.2.2.2. It seems weird but my reading of the standard does not make it incorrect.
> I'll look into it some more. The rest of the cases seem reasonable though.
The disagreement seems to be just about if NAN should have the positive sign. I didn't see anything in the standard but I'll take another look.

================
Comment at: test/localization/locale.categories/facet.numpunct/locale.numpunct.byname/thousands_sep.pass.cpp:58
@@ +57,3 @@
+        // GLIBC uses ' ' as the thousands_sep. That seems to be inline with
+        // http://docs.oracle.com/cd/E19455-01/806-0169/overview-9/index.html
+#       if !defined(__GLIBC__)
----------------
Dan Albert wrote:
> Interesting. According to that doc (and a bit of Googling), Mac's implementation is actually wrong here. I've found information claiming that the correct thousands separator for fr_FR.UTF-8 would be either '.', ' ', or, perhaps most accurately, '\u2009' (a thin space). Certainly not ',' though. My vote is that we lose the #ifdefs in this test and mark xfail for Mac.
> My vote is that we lose the #ifdefs in this test and mark xfail for Mac.

Although I'm very tempted to do this I'm not sure we should since there is no golden standard for locale data. I think we should just live with the fact different platforms are going to give use different results.
As you mentioned fr_FR can have a bunch of possible separators. This workaround isn't too ugly so my vote goes to leaving it in.

Can we get a tie-breaker from @mclow.lists or @emaste?

http://reviews.llvm.org/D4997