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: Sun, 19 Jun 2016 15:17:16 -0700
Organization: None to speak of
Lines: 42
Message-ID: <lnfus8su1f.fsf@kst-u.example.com>
References: <njkqfd$imt$1@solani.org> <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> <nju4og$e7v$1@dont-email.me> <nju897$qhn$1@dont-email.me> <njua9d$28q$1@dont-email.me> <nk0cjn$k1d$1@dont-email.me> <nk0hne$4k1$1@dont-email.me> <nk0l5l$fu4$1@dont-email.me> <nk0n8k$n8c$1@dont-email.me> <nk0r9i$5kj$1@dont-email.me> <a4496e67-03f3-46b0-851f-e57c0c66f548@googlegroups.com> <5765b041.31288640@news.xs4all.nl> <nk4p0s$vsn$1@dont-email.me> <093f5a15-0bd3-480e-aab3-91328adae12d@googlegroups.com> <nk4qrr$4j3$1@dont-email.me> <6304ebd4-4285-4e21-a6d6-c8f81af02803@googlegroups.com> <87oa6xqhos.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="7685"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+38L/80HJXYRhm63O8QDMo"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:MK1OXGADkCUE3FU8xpEHCR/TQ8M= sha1:C+EuwnyzjSwd6R9zZQ04ZTqtD0o=
Xref: csiph.com comp.lang.c:89629

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> <snip>
>> Very few systems push the stack for every block.
>> So the local block scopes are replaced by function scope variables.
>
> That's mixing up the scope and the lifetime.  This optimisation or
> implementation technique changes the lifetime of the object -- the scope
> of the identifier must stay the same or the compiler would break some
> programs.

Strictly speaking, it doesn't change the lifetime of the object; that's
defined by the standard.  The lifetime ends when execution reaches the
end of the enclosing block.  What the optimization does is cause the
memory to be deallocated only on return from the function.  An object's
lifetime can end while memory is still allocated for it.

Also, consider parallel nested blocks:

    void func(void) {
        int x;
        {
            int y;
            ...
        }
        {
            int z;
            ...
        }
    }

An implementation might allocate memory for all automatic objects
on entry to the function, and deallocate it all on exit, but
still store y and z in the same location.  Storage for y is not
deallocated at the end of its lifetime (in the sense of adjusting
the stack pointer or whatever), but it's reused for something else.

-- 
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"