Path: csiph.com!optima2.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!1.eu.feeder.erje.net!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: More physical source files Date: Tue, 30 Jun 2015 15:14:09 -0700 Organization: None to speak of Lines: 72 Message-ID: References: <36e79c40-a86d-416d-b290-b2de49560c61@googlegroups.com> <7cf2be57-a46a-454a-a6cb-0c81d77ed7fb@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="10572"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/DKacN04mWyEZPoch4BzTa" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:OACW49yGSr8MLPGs+mzBf4qt1nA= sha1:OVWC6wwZb2CF+0Rs/YcNYRQydzE= Xref: csiph.com comp.lang.c:64573 David Kleinecke writes: > On Monday, June 29, 2015 at 8:16:36 AM UTC-7, Keith Thompson wrote: >> David Kleinecke writes: >> [...] >> > But oddly enough it seems that the label colon could be replaced >> > everywhere by semicolons and the resulting language could be parsed >> > exactly the same as C. I am not purposing this - I just pointing out >> > something I had never observed before. >> >> No, it couldn't. >> >> This program; >> >> int main(void) { >> int n; >> n: >> ; >> } >> >> is syntactically valid; the "n:" is a label. If you change the >> colon to a semicolon, it becomes a reference to the int object. >> >> > It might be necessary to add >> > an explicit statment that >> > identifier SEMICOLON >> > is a label and not a meaning expression statement. >> >> That would be a change to the language. > > There is at least one other point where an ambiguity is resolved by > fiat. But I agree that is a change to the langauge. Which makes me wonder what the point of what you're doing is, but I didn't particularly understand it anyway. > I am thinking of compiler design - not formal adherance to the standard. I'd say adherence to the standard is a compiler's most important job. Of course if you want to have a compiler for a non-conforming dialect of C, that's fine. > A statment > identifier SEMICOLON > does nothing and any sane compiler will skip over it leaving a > warning behind. It is up to the compiler writer, of course, but > one might correct the "error" by changing the semicolon to a colon > (implicitly, of course) and warning about the change. It's valid for two reasons. First, an expression followed by a semicolon is a statement (and probably the most common kind of statement); there was no particular need to limit the expression to one with side effects. If you wanted to change that, you'd need to define the change. (And then an identifier followed by a semicolon could be treated as a label; I must have missed the part where you explained why that's a good thing.) Second, if the named object is volatile, a reference to it could have a side effect (though that's going to be system-specific). > To what extent would an error-corecting compiler be conforming? That depends on just how the "error-correcting" works. If it accepts valid programs and generates correctly behaving code for them, and diagnoses all syntax errors and constraint violations (and handles the #error directive correctly), then it's conforming. If not, it's not. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"