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

Groups > comp.std.c > #1627 > unrolled thread

VLAs use less stack

Back to article view | Back to comp.std.c

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

#1661

Le 04/09/12 02:39, Joe keane a écrit :
> Option 'c' is 'better', it works, except it may be slow.  Generally
> speaking i prefer code that is slow to code that doesn't work.

What GREAT alternatives:

either it doesn't work
or
it works but is slow.

Code that works and is efficient doesn't even appear in your horizon.
Too much to ask apparently.

[toc] | [prev] | [next] | [standalone]

#1652

Le 02/09/12 18:56, Joe keane a écrit :
> fixed-size array: fails at some point (can check for this)
> and variable-size array: fails at some point (can't check for this)

Interesting.

I start this thread with a complete example (source code provided) on 
how to check and limit the possible size of the stack allocation.

And now you say "can't check for this" as if nothing was said.

????

Can't you refer to the code I wrote?

Thanks

[toc] | [prev] | [next] | [standalone]

#1653

jgk@panix.com (Joe keane) writes:
[...]
> fixed-size array: fails at some point (can check for this)
> and variable-size array: fails at some point (can't check for this)
[...]

How can you check for failure of a fixed-size array?

For example:

    void func(void) {
        unsigned char buf[TOO_BIG];
        /* ... */
    }

If there isn't enough room (probably on the "stack") to allocate
TOO_BIG bytes, the behavior is undefined; you generally can't detect,
or recover from, an allocation failure.  The only difference VLAs
make is that the allocated size is not known at compile time,
and can be arbitrarily large if you don't compute the size carefully.

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

[toc] | [prev] | [next] | [standalone]

#1654

On 9/2/2012 2:37 PM, Keith Thompson wrote:
> jgk@panix.com (Joe keane) writes:
> [...]
>> fixed-size array: fails at some point (can check for this)
>> and variable-size array: fails at some point (can't check for this)
> [...]
> 
> How can you check for failure of a fixed-size array?

   If the program isn't recursive, and you do code coverage tests,
so that the worst case stack depth has been exercised,
you will either trigger that failure or demonstrate that it is
not going to happen.

   I once used a Modula compiler which calculated the worst
case stack depth at compile time.

				John Nagle

[toc] | [prev] | [next] | [standalone]

#1658

On 03.09.2012 00:45, John Nagle wrote:

>     If the program isn't recursive, and you do code coverage tests,
> so that the worst case stack depth has been exercised,

It's relatively easy to prove that this is impossible to achieve in the 
general case.  Even without VLAs you run into problems as soon as you 
have function pointer variables involved, because trying to predict 
which functions those can possibly point to, short of actually running 
the program with all possible inputs, is generally equivalent to the 
Halting Problem.  VLAs make that even more impossible, because even if 
you can build a known-complete call tree that still doesn't give you the 
actual stack size.

[toc] | [prev] | [next] | [standalone]

#1637

In article <k1q5bu$49h$1@speranza.aioe.org>,
jacob navia  <jacob@jspamsink.org> wrote:
>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.

agreed

But now you don't need VLAs!

    #define ZZ_STKSIZ 100

    int fn(size_t datasiz)
    {
	char databuf[ZZ_STKSIZ];
	char *p;
	int needfreep;
	int result;

	if (datasiz <= ZZ_STKSIZ)
	{
	    p = &databuf[0];
	    needfreep = 0;
	}
	else
	{
	    p = malloc(datasiz);
	    if (p == NULL)
	    {
		/* rollback */
		return EXIT_FAILURE;
	    }
	    needfreep = 1;
	}

    /* use p */

    if (needfreep)
	free(p);
    return result;
}

[toc] | [prev] | [next] | [standalone]

#1640

jgk@panix.com (Joe keane) writes:
> In article <k1q5bu$49h$1@speranza.aioe.org>,
> jacob navia  <jacob@jspamsink.org> wrote:
>>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.
>
> agreed
>
> But now you don't need VLAs!
>
>     #define ZZ_STKSIZ 100
>
>     int fn(size_t datasiz)
>     {
> 	char databuf[ZZ_STKSIZ];
> 	char *p;
> 	int needfreep;
> 	int result;
>
> 	if (datasiz <= ZZ_STKSIZ)
> 	{
> 	    p = &databuf[0];
> 	    needfreep = 0;
> 	}
> 	else
> 	{
> 	    p = malloc(datasiz);
> 	    if (p == NULL)
> 	    {
> 		/* rollback */
> 		return EXIT_FAILURE;
> 	    }
> 	    needfreep = 1;
> 	}
>
>     /* use p */
>
>     if (needfreep)
> 	free(p);
>     return result;
> }

Yes, that's something I suggested in my own followup.

Using a VLA rather than a fixed-size array does save some memory
space, though.  Taking your example of 100 bytes, a fixed-size
array means you *always* allocate 100 bytes (and more, via malloc(),
if you need more).  A VLA lets you allocate only what you actually
need in all cases, as little as 1 byte.

So there are two performance questions.  First, are malloc() and
free() expensive enough to justify the additional code complexity?
(I guess the answer to that is "sometimes".)  Second, is the
memory saved by using a VLA rather than a *small* fixed-size array
worthwhile?  Note that this saves much less memory than using
a VLA vs. using a fixed-size array that's big enough for *any*
possible requirement.

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

[toc] | [prev] | [next] | [standalone]

#1647

Le 01/09/12 18:09, Joe keane a écrit :
> But now you don't need VLAs!
>
>      #define ZZ_STKSIZ 100
>
>      int fn(size_t datasiz)
>      {
> 	char databuf[ZZ_STKSIZ];

Sure, but now you are wasting a some precious stack in some cases,
doing an expensive malloc in others.

VLAs are more FLEXIBLE! You use EXACTLY what you need in MOST cases.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.std.c

csiph-web