Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch
Newsgroups: comp.lang.c++
Subject: Re: Don't be fooled by cpp.sh
Date: Fri, 10 Jan 2020 14:19:05 -0800
Organization: A noiseless patient Spider
Lines: 17
Message-ID: <86ftgn3qg6.fsf@linuxsc.com>
References: <70391932-ccbc-4bc7-b693-881ab06eb6d3@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="7b070c0766e341d0df2bb5814a4c869f"; logging-data="14830"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19r7Op44LQSLDquXiVN4SWnV+BKBV2Ngu0="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:CMfnsd3eotPsSyk44ifjG2/cYmY= sha1:j5Hp8n2Qd+smPMo/YBEDfiYBPrE=
Xref: csiph.com comp.lang.c++:71267
Robert Wessel writes:
[...]
> VLAs present considerable implementation difficulties on some
> small systems,
Do you mean small in the sense of limited resources? Or small in
the sense of not having a full hosted library? What problems are
there in these small systems that don't come up in larger systems?
> and present a number of issues with regards to stack growth on all
> implementations
VLAs may present some issues with regard to stack growth, but they
don't have to. The Standard admits implemenations that put VLAs
somewhere other than on the stack, eg, allocated with malloc().