[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEX4NpRJP+ricsDidittgks8sMNAp3hUBFFRfBZ9oWSmimWM8Q@mail.gmail.com>
Date: Tue, 5 Aug 2014 14:10:25 -0700
From: Alon Zakai <alonzakai@...il.com>
To: musl@...ts.openwall.com
Subject: Re: Bug report on iswalpha
I see what you mean, yes, this does seem like undefined behavior then, as
it's invalid in that locale. Thanks for the quick response!
And thanks for musl in general! We are very happy with it in the emscripten
project.
- Alon
On Tue, Aug 5, 2014 at 2:02 PM, Rich Felker <dalias@...c.org> wrote:
> On Tue, Aug 05, 2014 at 01:35:27PM -0700, Alon Zakai wrote:
> > I think we have encountered a bug in iswalpha, as shown by the following
> > program:
>
> At least an inconsistency with glibc. Not necessarily a bug.
>
> > ====
> > #include <locale.h>
> > #include <stdio.h>
> > #include <wctype.h>
> >
> > int
> > main(const int argc, const char * const * const argv)
> > {
> > const char * const locale = (argc > 1 ? argv[1] : "C");
> > const char * const actual = setlocale(LC_ALL, locale);
> > if(actual == NULL) {
> > printf("%s locale not supported; skipped locale-dependent code\n",
> > locale);
> > return 0;
> > }
> > printf("locale set to %s: %s\n", locale, actual);
> >
> > const int result = iswalpha(0xf4); // รด
> > printf("iswalpha(\"\xc3\xb4\") = %d\n", result);
> > return 0;
> > }
> > ====
> >
> > It returns 1 in the final printf, saying that that char is an walpha
> char,
> > when I believe it is not. For comparison, glibc reports 0.
> >
> > Tested on musl 1.0.3 (used in emscripten) and musl trunk on git, same
> > result.
>
> Expecting iswalpha(0xf4) to return 0 in the C locale is wron, since
> 0xf4 has not been established to be valid wchar_t value in the current
> locale, and the behavior of iswalpha is _undefined_ unless the
> argument is either WEOF or a valid wchar_t in the current locale.
>
> As documented, musl's C locale contains all of Unicode, and
> additionally classifies all Unicode characters into the C classes like
> "alpha", etc. based on their Unicode identities. This behavior is
> definitely conforming to the requirements of ISO C and likely (though
> the specification is not entirely clear) conforming to the current
> requirements of POSIX, but is expected to be forbidden in future
> issues of POSIX.
>
> This is actually a topic of current discussion and possible change
> (depending on what happens in POSIX), but I don't think the behavior
> of iswalpha is likely to change in any case. If the C locale in musl
> is changed not to include all of Unicode, then iswalpha(0xf4) would
> just be undefined behavior in the C locale, and there would be no
> reason to make it check the locale and return false. If the above code
> is part of a test, I think it's an invalid test. With a better idea of
> what it's trying to test, I could possibly suggest a fix that avoids
> the UB.
>
> Rich
>
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
