Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: Small Device C Compiler 3.6.0 released
Date: Wed, 15 Jun 2016 18:01:57 -0700
Organization: None to speak of
Lines: 70
Message-ID: <lnvb1avtdm.fsf@kst-u.example.com>
References: <njkqfd$imt$1@solani.org> <njolq7$hrh$1@dont-email.me> <87mvmoymg9.fsf@bsb.me.uk> <njp3t6$596$1@dont-email.me> <njr34n$g6n$1@dont-email.me> <njr777$tjj$1@dont-email.me> <njrc6p$fcj$1@dont-email.me> <njreq9$oki$1@dont-email.me> <njrgks$vkn$1@dont-email.me> <lnwplqz9ji.fsf@kst-u.example.com> <njs3qt$bak$1@dont-email.me> <ln7fdqz3wq.fsf@kst-u.example.com> <njs91t$vl6$1@dont-email.me> <lny466xnle.fsf@kst-u.example.com> <njsb4u$7j9$1@dont-email.me> <lnporixk5g.fsf@kst-u.example.com> <njsfk4$o0e$1@dont-email.me> <lnh9cuxh6x.fsf@kst-u.example.com> <njskpp$ctg$1@dont-email.me> <ln4m8uxbcq.fsf@kst-u.example.com> <njsqsf$tg8$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="4749"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/fhpJ2emqD4PNmfOR+g8Fe"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:QUQHzd6UtlMTP3X8AEvdDFeLeYM= sha1:K4dM7nCWtFf3bJRQOfztfYdLN58=
Xref: csiph.com comp.lang.c:89243

BartC <bc@freeuk.com> writes:
> On 16/06/2016 00:48, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
[...]
>>> 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.)
>
> Do you understand what the one-name-per-block policy is about? If not 
> then that then will explain why you can't make head or tail of my proposal.

I think "one name per block" is a confusing way to express the idea.

You object to the fact that the same name can refer to different
entities depending on where you are in the block, right?

    {
        int a;
        {
            a = 10; // refers to the outer `a`
            int a;
            a = 20; // refers to the inner `a`
        }
    }

The *scope* of an identifier is by definition the region of program text
in which it's visible (N1570 6.2.1p2).  So when you talk about extending
the *scope* of an identifier, that tells me you want it to be *visible*
over a wider range of program text.

Logically, such a change would affect the simpler case I presented:

    {
        a = 10;
        int a;
    }

In fact you don't care whether the inner `a` in the first example above
is visible before its declaration or not.  Your entire point is to
ensure that the outer `a` is *not* visible over the entire inner block.

I got caught up on what you were actually saying, as opposed to what you
meant.

Here's a different way to solve the problem:

    Constraint:

    An identifier shall not be redeclared in an inner block if an outer
    occurrence of the same identifier has been referred to in the same
    block prior to the redeclaration.

(I haven't spent enough time to get the wording just right.)    

It requires no change to the scoping rules.  It just requires a
diagnostic for the case that bothers you.

I do not advocate any such change.  Compiling with "gcc -Wshadow"
suffices to avoid the problem with no language changes (admittedly
that doesn't help if you're using a compiler that doesn't have
"-Wshadow" or equivalent).  I haven't found shadowing to be a
problem worth solving anyway; I might have run into it a small
handful of times.  But if you wanted to change the language to
avoid the problem, I suggest that's a better way to do it.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
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"