On Sat Feb 22 21:27:22 2014, khw wrote:
I sent Jim a C program to print the radix characters. It showed for
that the radix was a string of two characters: An apostrophe followed
by a space. Since Craig isn't having this problem on his later
version of libc, this appears to be a bug in these locales that has
since been fixed. I was wrong when I told Jim offlist that a single-
byte locale, such as 8859, can only have a single byte radix
character. In fact the radix is a string, so this is legal POSIX . I
*think* also that Perl can cope with a multi-char radix, but it can't
cope with this one. From the error messages, it is likely that Perl
can't handle a quote character being part of a decimal point. As I
said above, I don't believe it's worth fixing this, given until and if
we are ever presented with a legitimate locale that has this
The reason this hasn't shown up before is the same reason the
Lithuanian locales used to pass. I have added a lot of locale tests
in 5.19 that never were there before. In this case, it started
failing when I added some new radix tests. (In the Lithuanian case,
tests for upper/lowercase pairs showed that the ENG character casing
hasn't been implemented correctly).
locale.t has also been updated so that if a certain percentage of
tests on a machine pass completely, the failures don't fail the test
as a whole. For most platforms the number is >5% failure triggers the
whole test failing. The percentage can be varied depending on
platform. For MSWindows, every locale but the C locale has at least
one violation of the POSIX standard, so the acceptable percentage of
failures is 99.9%.
Rather than make special cases for these tests, I think the general
mechanism is good enough. If it's the case that these failures are
pushing the failure rate too high for this platform and OS version,
then we can up the acceptable failure rate enough to get it to pass.
Karl, thank you for the time and effort you have put into this investigation.
Let me see if I understand the situation correctly. The problem I reported had two parts.
First, 5 unit tests in lib/locale.t that had been passing for many years suddenly started to fail. With the recent renumbering of the tests, those tests are now:
not ok 295 Verify that a different locale radix works when doing "==" with a constant
not ok 296 Verify that a different locale radix works when doing "==" with a scalar
not ok 300 Verify that "==" with a scalar and an intervening sprintf still works in inner no locale
not ok 303 Verify that after a no-locale block, a different locale radix still works when doing "==" with a scalar and an intervening sprintf
not ok 305 Verify that don't get warning under "==" even if radix is not a dot
Second, the number of failing locales on this platform increased from 2 to 6:
eu_ES eu_ES.ISO8859-1 eu_ES.ISO8859-15 eu_ES.UTF-8
The 4 eu_* locales are new failures; the 2 lt_* locales are problematic even on more recent versions of Darwin.
The FAIL which I am getting in lib/locale.t on Darwin/PPC is caused by the 5 'not ok' tests, i.e., the first problem. The FAIL is not, per se, caused by the increased number of problematic locales.
The overall FAIL in lib/locale.t is causing 'make test' as a whole to FAIL on this platform. Hence, to get 'make test' to PASS, we need to address the 5 failing unit tests. In other contexts (t/io/eintr.t) we have tested for platform and OS version and simply SKIPped tests known to fail on a certain platform. Would that be acceptable here?
Thank you very much.
via perlbug: queue: perl5 status: openhttps://rt.perl.org/Ticket/Display.html?id=121079