Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Small Device C Compiler 3.6.0 released Date: Wed, 15 Jun 2016 16:48:21 -0700 Organization: None to speak of Lines: 138 Message-ID: References: <87pork1zyk.fsf@bsb.me.uk> <87mvmoymg9.fsf@bsb.me.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="26538"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/5Ilkb9Qw0K/Mk6TxgG1+N" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:sGfRcqs3AdIue6VZgBMZDO58WPk= sha1:Ehtu2UgKaQClTXOI2tOq1Bo/d5I= Xref: csiph.com comp.lang.c:89237 BartC writes: > On 15/06/2016 22:42, Keith Thompson wrote: >> BartC writes: >>> On 15/06/2016 21:38, Keith Thompson wrote: > >>> Under the proposal, this changes to: >>> >>> {int A; // outer A >>> { P; // inner A >>> Q; // inner A >>> A=10; // inner A (but may need reordering... >>> R; // inner A >>> int A; // inner A >>> S; // inner A >>> T; // inner A >>> } // outer A > >> (Since you seem to agree that declarations *should* precede usage, >> it seems that the only purpose of your proposed change is to change >> the handling of shadowed identifiers. Avoiding shadowed identifiers >> is IMHO a much easier way to do that.) > > I look at this from the implementation POV as well. I see it as a > problem that a block can be associated with two identical names at the > same 'time', and with an untidy 'switch-over' somewhere along the block. > Simply avoiding such a situation isn't really dealing with it; the > implementation still needs to support it. Other people's code can have > it. The possibility is always there. > > I've noticed also that this appears not to be legal: > > {int A; > {if (cond) int A; Of course not. It's a syntax error. The syntax for an if statement is if ( expression ) statement and a declaration is not a statement (though it can be part of a statement). > You apparently can't have a declaration as the sole statement of an If > or Loop statement. Which clearly would have created some problems! But > you can however write this: > > {int A; > { if (!cond) goto L1; > int A; > L1: > A=20; Right. > So, if cond is false, is the inner A being set to 20, or the outer one? > Comment sense says it's the inner one, even if the declaration is > skipped; presumably it's not an actual executable statement, the > variable is always created. (Unless it's initialised I suppose.) That's some ugly code, but it's unambiguous. `goto L1;` is a statement, so there's no syntactic problem with the if statement. The presence of the label `L1:` doesn't affect scoping. So the assignment `A=20;` refers to the inner `int A;` defined two lines above, not the one defined in an outer scope. (If `A` were initialized and the goto were executed, it would skip over the initialazation; `A` would exist but would have an indeterminate value. So don't do that.) >> **BUT** >> >> Upthread, when I asked: >> >> Under your proposal, would this be legal (assuming no outer >> declaration of n)? >> >> { >> n = 20; >> int n; >> } >> >> you replied: >> >> As I said, it could be, but it's better for the reasons I listed >> that the declaration was moved. (This code could generate an error >> or warning.) >> >> Under your most recent description, that 4-line chunk of code would be >> perfectly legal, and the "n" in the assignment would refer to the object >> "n" defined on the next line. >> >> Let's ignore for now the question of whether it would be good style, and >> of whether a compiler might generate a warning for it. >> >> (This code could generate an error or warning.) >> >> What did you mean by that? How could it generate an error if it's >> legal? > > When a reference to a name precedes its declaration, the answers simply > aren't clear-cut. Then what's the bloody point? You propose a language change to extend the scope of a declaration, but in the only cases where it could possibly matter "the answers simply aren't clear-cut". The answers certainly *could* be clear-cut if you wanted to make them so. > It wouldn't bother me if the example was legal and worked as expected. > But I thought you liked the fact that (i) names ought to be declared > befor use; and (ii) the point of having declarations in odd places was > *so* you can declare a variable at it's first point of use. (*sigh*) As I've already said, I personally dislike your proposal. Given that, I've still been trying to find out just what your proposal is. Yes, names ought to be declared before use. In C, they *have* to be. Why are you proposing a change that would permit variables to be used before declared? Or are you proposing such a change? I can't tell. > Then you might want to do something about that, which can include making > the code generate an error. As a C compiler will already do, with no changes to the language. > However the problem with making the above work (setting the inner n to > 20), is that currently C works differently (it will set an outer n to 20 > if there is one visible, or an error is raised). > > But I'm not too bothered provided there is a one name-per-block policy. I give up. (I probably should have done so sooner.) -- 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"