Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: Dinamic array without malloc - Can be done?
Date: Sun, 15 Jan 2017 12:51:05 -0800
Organization: None to speak of
Lines: 35
Message-ID: <lninpggi86.fsf@kst-u.example.com>
References: <863e4550-027a-4d32-b5df-e34f2c7b4439@googlegroups.com> <o5gcm9$lu4$1@dont-email.me> <01610cdf-e6ca-47ac-ba40-b597b0c524d0@googlegroups.com> <o5gipt$vq0$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: mx02.eternal-september.org; posting-host="a3056e3d6a9ef9101ceee550b325befe"; logging-data="4387"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+f7/Ulex9gB8nYxGjCB8rM"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:dlfwTert2XVwgzY6h1ckz8vWa68= sha1:iCFgZ7O9OS8QGDwsY6OSL30rr50=
Xref: csiph.com comp.lang.c:101881

Richard Heathfield <rjh@cpax.org.uk> writes:
[...]
> Since you seem not to have access to VLAs, I'm going to dare to suggest 
> a non-ISO function: alloca() (or _alloca() under Visual Studio).

It turns out the OP does have access to VLAs.

> This works just like malloc, except that it automagically frees the 
> memory when the calling function returns, which is what would have 
> happened anyway with your char arr[len] code, so it would seem to be 
> exactly what you're asking for.
>
> This is not, however, an ISO C function. If I understand the rules 
> correctly, I must therefore now hand in my "comp.lang.c - Purist And 
> Proud Of It" badge for a two-week penalty period.

alloca() is neither ISO C nor POSIX, though it's supported on a lot of
Unix-like systems.

Be aware that if an alloca() call causes stack overflow, the behavior is
undefined.  The same is true for defining a VLA.  Then again, the same
is true for an old-style constant-length array.  If you use a VLA to
avoid allocating more memory than you need for a local array, you
probably haven't introduced any additional risk.  If a VLA might be
bigger than a constant-length array would have been, you have no way to
deal with stack overflow.

Another limitation: You can't have an alloca() call in the argument list
for a function call.

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