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: Are there any conformant C compilers? Date: Thu, 25 Aug 2022 12:25:43 -0700 Organization: None to speak of Lines: 69 Message-ID: <87czcoktvs.fsf@nosuchdomain.example.com> References: <87v8qgw9m1.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Info: reader01.eternal-september.org; posting-host="a042aa527780c44e7e71460682553b9b"; logging-data="3906412"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/inUTp4i4UtiICK6KloJZu" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:VmVRjeth3LqqKzQL0kS1mRNO7nA= sha1:vfVmkhkexawMIna33GMgypyc1Wk= Xref: csiph.com comp.lang.c:167221 bart c writes: > On Thursday, 25 August 2022 at 17:50:45 UTC+1, Keith Thompson wrote: >> bart c writes: >> > On Thursday, 25 August 2022 at 03:33:57 UTC+1, anti...@math.uni.wroc.pl wrote: >> [...] >> >> In principle compiler which is doing aggressive constant >> >> folding during macro expanson could easily compile this >> >> program, but it is not clear if any is doing this. >> > >> > I don't think it's possible. The preprocessor doesn't understand C >> > expressions. The only expressions it knows about are used with #if, >> > and those have their own rules. Yes, but the rules are similar, and the operator precedence rules are exactly the same. >> > Evaluating a C expression, so that `2 + 2` yields the token '4', >> > requires knowledge of C types, but also, if the full sequence was `2 + >> > 2 * 3`, knowledge of C's operator precedences. > >> `2 + 2 * 3` is a valid preprocessor expression, usable in `#if`, so the >> preprocessor has to be able to evaluate it at compile time. > > My post made a distinction between a preprocessor expression '2+2*3', > used in contexts like `#if`, and the C expression '2+2*3', used > outside that special CPP context, and which can incorporate a bunch of > other C syntax that the CPP should know nothing about, even apart from > the type rules of C. > > The logistics just don't work. Even if it could isolate "(2+2)" and > turn that into "4", which you might think is a safe conversion, that > token sequence may itself be processed further when passed as another > macro parameter, eg. it could be stringified. Then you need it to stay > as it is. > > C's type rules (on 64-bit machines) mean that arithmetic is normally > done at 32 bits, but CPP arithmetic is done at 64 bits. > > Maybe this reduction is possible with a hairy enough processors (even > more hairy than they already are just to do their job), but the OP > hasn't observed that to be the case. I think I skipped over the "yields the token '4'" part of what you wrote above. `2 + 2 * 3` is a valid preprocessor expression, usable in `#if` In that context, the preprocessor has to evaluate it -- not to the token `8`, but to the value 8`. Outside a preprocessor directive, it's a valid expression (if it appears in an expression context). Some contexts require it to be evaluated at compile time -- and most compilers are likely to do so regardless of the context. For example, given `int n = 2 + 2 * 3;` I wouldn't expect any production quality compiler to generate add and multiply instructions. But you were talking about something like having the preprocessor replace the token sequence `2 + 2 * 3` with the token `8` outside any preprocessor directives. Yes, it would be very difficult to do that correctly, and the only purpose would be guard against exploding macro expansions as in the parent article of this thread. It's probably just not worth doing. (BTW. I had to reboot my computer after attempting to compile the program in the parent article of this thread. Beware. -- 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 */