Path: csiph.com!news.mixmin.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Cake - C23 to C99 transpiler Date: Wed, 14 Sep 2022 07:14:38 -0700 Organization: A noiseless patient Spider Lines: 66 Message-ID: <86tu5am4a9.fsf@linuxsc.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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader01.eternal-september.org; posting-host="e4a07c6eb40a7dcf36ed28254bbf399a"; logging-data="3147276"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Yj3d0IIAEQL0r74d3Os/N2YwtVquQZjM=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:2Pr+HWXcX2NK6inkfdPKeZ8IJ+M= sha1:KeXjZv6cNJ+OrN6vt9XiuVxUuaI= Xref: csiph.com comp.lang.c:167712 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. > 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. > A conforming C23 implementation can still accept '$' in identifiers > as an extension, but my understanding is that it must issue a > warning. If accepting '$' is only an extension, and not a consequence of some implementation-defined behavior, then using '$' in an identifier results in a syntax error, which requires a diagnostic. Where is the uncertainty? > In any case, as of C11 a conforming C compiler is not required to accept > '$' in identifiers *at all*, even with a command-line option, and may > reject any program that uses it. You can of course choose to rely on > the behavior of specific compilers, but if you use '$' in identifiers > then your code is not 100% portable. (REMINDER: "not 100% portable" is > not necessarily a criticism.) Yes.