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().