> 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
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
