Path: csiph.com!news.mixmin.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Cake - C23 to C99 transpiler Date: Wed, 14 Sep 2022 10:59:27 -0700 Organization: None to speak of Lines: 64 Message-ID: <87k065hm68.fsf@nosuchdomain.example.com> References: <836c6515-87f5-42b2-98b0-8308173a9120n@googlegroups.com> <8735d39ou5.fsf@bsb.me.uk> <87leqv87t2.fsf@bsb.me.uk> <87fsh386ze.fsf@bsb.me.uk> <8735d380ta.fsf@bsb.me.uk> <87tu5ikivi.fsf@nosuchdomain.example.com> <86tu5am4a9.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Info: reader01.eternal-september.org; posting-host="8fc111422276ca8204b941f03dd9cf79"; logging-data="3214206"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18exjzI74QiwgR9jlLUHJzC" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:hG0wFCWM8leoMIeh9amEPCtHK+M= sha1:1SenAGGquw5+zmOqeueoIecMAwQ= Xref: csiph.com comp.lang.c:167723 Tim Rentsch writes: > Keith Thompson writes: >> Bart writes: >> [...] >> >>> Also, gcc gets away with allowing $ by default; tcc generally copies >>> gcc in terms of how a compiler is invoked, so this surprisingly goes >>> against that. >> >> gcc allowing $ in identifiers is a documented extension for most >> targets, so it doesn't warn about them even with "-pedantic". One could >> argue that this isn't necessarily an "extension", since "other >> implementation-defined characters" are explicitly permitted by C11 >> 6.4.2.1. >> >> Interestingly, the C23 draft doesn't have that wording. Instead, it >> allows XID_Start and XID_Continue characters, so it expands the set of >> characters that *all* implementations must support, > > I believe that conclusion is not correct. The C23 draft n3047 says > this: > > An XID_Start character is an implementation-defined character > whose corresponding code point in ISO/IEC 10646 has the > XID_Start property. An XID_Continue character is an > implementation-defined character whose corresponding code point > in ISO/IEC 10646 has the XID_Continue property. > > The presence of the modifying adjective "implementation-defined" in > both cases surely means, at the very least, that implementations > are allowed to subset the Unicode-specified XID_Start/XID_Continue > sets with regard to what characters are allowed in identifiers. You're right. I managed to miss the phrase "implementation-defined". So ISO/IEC 10646 defines which characters have the "XID_Start" property, but an "XID_Start" character is a member of a C implementation-defined subset of those characters. The terminology is a bit confusing, but I'm not sure how I'd improve it. >> but doesn't permit '$' (assuming '$' isn't in XID_Start or >> XID_Continue). > > I'm not sure this statement is right either (and agreeing with the > assumption that '$' is not in XID_Start or XID_Continue). The > Unicode reference documentation is so bad that I can't make out > with any degree of certainty whether it allows various domains to > extend the XID_Start/XID_Continue sets for the application in > question. The presence of "implementation-defined" further muddies > the waters. To be clear, neither am I saying that I think the > statement is wrong; only that at present there is not enough > information to be confident of either conclusion. If '$' can't be an XID_Start or XID_Continue character, then an attempt to use '$' in an identifier is a syntax error. I don't see any wiggle room there. The open question is whether '$' is, or can be, an XID_Start or XID_Continue character. [...] -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips void Void(void) { Void(); } /* The recursive call of the void */