[LLVMbugs] [Bug 21506] New: libc++ should have its own classic_table

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Thu Nov 6 13:24:37 PST 2014


http://llvm.org/bugs/show_bug.cgi?id=21506

            Bug ID: 21506
           Summary: libc++ should have its own classic_table
           Product: libc++
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: danalbert at google.com
          Reporter: danalbert at google.com
                CC: eric at efcs.ca, jonathan at codesourcery.com,
                    llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com
    Classification: Unclassified

We should probably be shipping our own classic_table instead of relying on one
from the underlying C library.

1. The C library isn't required to even provide such a table. IIRC, musl does
not.
2. The underlying type of the table is undefined, as are the values that map to
each mask. This is responsible for the #ifdef hell stew in [1].
3. Some C libraries (bionic, openbsd, and newlib, possibly others) use an 8-bit
mask for the table. It's still not 100% clear if this is okay, or if we need to
be able to define more than 8 values such that for any two values a and b, a &
b == 0. There are known failures in some libc++ tests [2] caused by this.
Defining our own table with a mask that is at least 16-bits wide (possibly 32)
would get us out of this mess.

I'll upload a patch soonish (once I find time) that does this unless anyone has
good reasons not to take this approach.

[1]: https://github.com/llvm-mirror/libcxx/blob/master/include/__locale#L324
[2]:
localization/locale.categories/category.ctype/locale.ctype.byname/is_1.pass.cpp
localization/locale.categories/category.ctype/locale.ctype.byname/scan_is.pass.cpp

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141106/b4394ac8/attachment.html>


More information about the llvm-bugs mailing list