[cfe-dev] Patch for UCNs in string literals
dgregor at apple.com
Mon Jul 6 09:28:29 PDT 2009
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?
> 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
More information about the cfe-dev