[cfe-dev] Patch for UCNs in string literals

[Douglas Gregor]

On Jul 6, 2009, at 2:41 AM, AlisdairM(public) wrote:

>> -----Original Message-----
>> From: Eli Friedman [mailto:eli.friedman at gmail.com]
>> Sent: 05 July 2009 12:45
>> To: AlisdairM(public)
>> Cc: clang-dev Developers
>> Subject: Re: [cfe-dev] Patch for UCNs in string literals
>
>> There are also working drafts available for C99, for example
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1336.pdf .  That
>> said, we don't have the C tests structured that way, and I'm not sure
>> it's really worth the effort at this point, so just name it something
>> reasonable and put it in with the existing tests.
>
> Thanks.  I just found n1362 which seems to be the latest draught.   
> Do we have any plans for an experimental C1x mode yet?  For example,  
> I notice that this draught now has support for static_assert and  
> Unicode types and literals.

No plans, but we'd be happy to put in the flags for a C1x mode.

> Given we already implement static_assert for C++0x, I imagine it  
> should be fairly easy to adapt for _Static_assert in C1x mode.

How interesting. C1x _Static_assert is identical to C++0x  
static_assert, then <assert.h> #defines static_assert to _Static_assert.

Should be a trivial matter to support C1x's _Static_assert with the  
same implementation as C++0x's static_assert. Patch welcome :)

> The Unicode characters give me more pause (which I am looking to  
> implement for C++0x).  The C standard does not spell out a specific  
> name for these types, but defers them to uint_least_16/32_t.   
> However, I believe the string literals are usable even when this  
> header has not been included, and obviously those typedefs might  
> resolve to different types on different platforms.

We should know what uint_least16/32_t are from our target information,  
so we can just dig out that appropriate integral type. However, it's  
unfortunate that these types don't have a name that would be  
recognizable in diagnostics. (What's a character string of type const  
int*, anyway?) Smells like a design problem.

> What would be the best way to support this for C?  I had originally  
> thought that C defined two new types, _Char16_t and _Char32_t just  
> as it introduces _Bool, but that does not seem to be the case.

The best way might be to convince the C committee to add _Char16_t and  
_Char32_t. C1x is still young and incomplete.

> On the subject of C testing of UCNs, where should I put this test?   
> Does test/lexer/universal_char_name.c sound right?

Sure.

> Again, what should I do about the XFAIL wide-char tests? (other than  
> implement the support ;¬)


We can add a new XFAIL tests (in a separate .c file), and will revisit  
them when someone gets around to implementing more support for wide  
characters.

   - Doug