Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.std.c > #1632

Re: VLAs use less stack

Show all headers | View raw

jacob navia <jacob@spamsink.net> writes:
> In many cases, when needing a buffer the programmer has to use
>
> #define MAXDATA	1024
> int fn(int datasiz)
> {
>      char fullPath[MAXDATA];
> }
>
> using the worst possible case as the normal case. Most datasets will be
> much smaller but you HAVE to use the biggest possible.

How common is that in practice?  In the absence of VLAs, if you don't
know in advance how big the buffer needs to be, isn't it more common to
use malloc() (and possibly realloc())?

> Now, if you use VLAs you could write:
> int fn(int datasiz)
> {
>      char fullPath[datasiz];
> }
>
> using in the average case much less stack than above.
>
> Critics to VLAs would say that this opens the door to an unlimited use
> of the stack, what in the above example is true.

Which, as you know, means that you can't detect, much less handle, an
allocation failure.  (Just clarifying.)

>                                                  But it is NOT true that
> this is impossible to avoid:
>
> int fn(size_t datasiz)
> {
>      char databuf[datasiz<1000?datasiz:1];
>      char *p;
>      int result;
>
>      if (datasiz >= 1000) {
>          p = malloc(datasiz);
> 	if (p == NULL {/*error handler here */
>               return EXIT_FAILURE;
>          }
>      }
>      else p = & databuf[0];
>      // Use p here
>      if (datasiz>=1000) free(p);
>      return result;
> }
>
> Here we have the best path: In MOST cases we will use a cheap stack
> allocation. In the few cases where the data size is exceptionally big
> we use the more costly heap allocation. We can handle an unbounded
> amount of data.
>
> It would be nice if we would put this examples in a visible part of the 
> internet...
>
> (If you agree of course)
>
>
> Essentially the myth that VLAs are UNBOUNDED must be debunked. They can
> be bounded!

Interesting idea.  But I wonder how often it's really worthwhile
in practice.  In terms of code complexity, it offers no advantage
over using malloc/free uconditionally; you still have to make sure
you call free() if the buffer was allocated with malloc(), so you
lose that advantage of VLAs.

The only advantage it offers over using malloc/free unconditionally
is that it avoids the overhead of the malloc and free calls for
small buffers.  Are malloc and free really expensive enough for
this to be a worthwhile optimization?  The tradeoff is likely to
vary from one system to another.  (I'm not trying to imply that
it's *not* worthwhile; I haven't measured it myself, and I'm asking
because I honestly don't know.)

Note that if you're using a compiler that doesn't support VLAs
(because it's pre-C99, or because it's a C11 compiler that defines
__STDC_NO_VLA__), you can still do something similar using a
fixed-sized array.  It's slightly more wasteful of "stack" space
(which is the point you're making), but with a small enough fixed
size it could be reasonable.  One good use case is reading lines
of text, where most lines are expected to be short but you want to
handle arbitrarily long lines.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Back to comp.std.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

VLAs use less stack jacob navia <jacob@spamsink.net> - 2012-08-31 12:58 +0200
  Re: VLAs use less stack Marc <marc.glisse@gmail.com> - 2012-08-31 14:10 +0000
    Re: VLAs use less stack Marc <marc.glisse@gmail.com> - 2012-08-31 14:13 +0000
    Re: VLAs use less stack jacob navia <jacob@spamsink.net> - 2012-08-31 18:09 +0200
    Re: VLAs use less stack jacob navia <jacob@spamsink.net> - 2012-08-31 18:14 +0200
    Re: VLAs use less stack John Nagle <nagle@animats.com> - 2012-09-01 12:24 -0700
      Re: VLAs use less stack jacob navia <jacob@spamsink.net> - 2012-09-01 22:57 +0200
      Re: VLAs use less stack jacob navia <jacob@spamsink.net> - 2012-09-01 22:59 +0200
  Re: VLAs use less stack Keith Thompson <kst-u@mib.org> - 2012-08-31 11:42 -0700
    Re: VLAs use less stack Marc <marc.glisse@gmail.com> - 2012-09-01 10:18 +0000
      Re: VLAs use less stack Rui Maciel <rui.maciel@gmail.com> - 2012-09-01 19:18 +0100
        Re: VLAs use less stack Marc <marc.glisse@gmail.com> - 2012-09-01 19:19 +0000
        Re: VLAs use less stack jacob navia <jacob@spamsink.net> - 2012-09-01 23:01 +0200
      Re: VLAs use less stack Keith Thompson <kst-u@mib.org> - 2012-09-01 11:36 -0700
        Re: VLAs use less stack Marc <marc.glisse@gmail.com> - 2012-09-01 19:05 +0000
    Re: VLAs use less stack jgk@panix.com (Joe keane) - 2012-09-02 16:56 +0000
      Re: VLAs use less stack Keith Thompson <kst-u@mib.org> - 2012-09-02 14:22 -0700
        Re: VLAs use less stack jgk@panix.com (Joe keane) - 2012-09-04 00:39 +0000
          Re: VLAs use less stack Jens Gustedt <jens.gustedt@loria.fr> - 2012-09-04 10:28 +0200
            Re: VLAs use less stack John Nagle <nagle@animats.com> - 2012-09-04 11:31 -0700
          Re: VLAs use less stack jacob navia <jacob@spamsink.net> - 2012-09-04 17:02 +0200
      Re: VLAs use less stack jacob navia <jacob@spamsink.net> - 2012-09-02 23:28 +0200
      Re: VLAs use less stack Keith Thompson <kst-u@mib.org> - 2012-09-02 14:37 -0700
        Re: VLAs use less stack John Nagle <nagle@animats.com> - 2012-09-02 15:45 -0700
          Re: VLAs use less stack Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-09-04 00:03 +0200
  Re: VLAs use less stack jgk@panix.com (Joe keane) - 2012-09-01 16:09 +0000
    Re: VLAs use less stack Keith Thompson <kst-u@mib.org> - 2012-09-01 11:45 -0700
    Re: VLAs use less stack jacob navia <jacob@spamsink.net> - 2012-09-01 23:05 +0200

csiph-web