Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: Future of C
Date: Thu, 15 Mar 2018 10:35:57 -0700
Organization: None to speak of
Lines: 22
Message-ID: <lnwoyd6y2q.fsf@kst-u.example.com>
References: <0231327b-9e28-46e4-9178-46c881a8dd91@googlegroups.com> <20180311161525.ac591de531b83d6b14b2cd43@gmail.com> <90236828-48d7-4ee5-9b86-4cedd0e29b5f@googlegroups.com> <hwhpC.902622$F74.120435@fx47.am4> <d9d91c28-fb38-400b-8b92-ce7ce7d2b9cd@googlegroups.com> <3r7jne-t3h.ln1@gangtai.grep.be> <8e201938-ada4-42d9-8ae6-13b1047306e2@googlegroups.com> <tmhkne-4af.ln1@gangtai.grep.be> <p88thk$6ce$1@dont-email.me> <lpUpC.8300$TP2.7319@fx01.am4> <p89c98$na6$1@dont-email.me> <0iXpC.1451$kF1.89@fx41.am4> <p8b317$998$1@dont-email.me> <40d27639-bea8-460a-add2-f5ad2f26cbdc@googlegroups.com> <p8bh23$bqk$1@dont-email.me> <5e80c990-fe53-4d7e-8a81-bc411cc21d76@googlegroups.com> <lnvady8oa0.fsf@kst-u.example.com> <2ac9ccf7-5b25-4822-8dbd-5b749bed2c07@googlegroups.com> <lnr2om8kc1.fsf@kst-u.example.com> <f0c0d057-6c7e-47bf-a10e-c6a7184da614@googlegroups.com> <p8dg2o$ghj$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="4062d3804107f3b0a8439aa53526a52c"; logging-data="4354"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/fVBl1EST7oGcTg9LJN26m"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:FXAzlFsgRyx0vL/IK3iFH7wdI/w= sha1:qPLPYqoPKNQ3bRm1mDN5kzCDQQo=
Xref: csiph.com comp.lang.c:127879

David Brown <david.brown@hesbynett.no> writes:
[...] 
> In particular, note that MSVC supports alloca().  VLAs are utterly
> trivial when you have alloca() support - you can get a correct (albeit
> possibly suboptimal) implementation with some syntactic sugar and using
> the alloca() mechanism to get the local memory.  It does not matter for
> correctness that alloca() memory may have a longer lifetime than the VLA
> memory.

A VLA implementation that only deallocates on return from the
enclosing function might be conforming, but it would have some
serious problems.  Consider a program that defines a VLA in a loop.
If each VLA is deallocated at the end of of its lifetime, there's
no problem.  If each VLA is deallocated at the end of the function,
you've got a memory leak.  (We've been discussing an example elsewhere
in this thread.)

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