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

Groups > comp.lang.c > #101847 > unrolled thread

Dinamic array without malloc - Can be done?

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

Contents

  Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 08:45 -0800
    Re: Dinamic array without malloc - Can be done? BartC <bc@freeuk.com> - 2017-01-15 16:53 +0000
      Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-15 09:34 -0800
        Re: Dinamic array without malloc - Can be done? BartC <bc@freeuk.com> - 2017-01-17 21:09 +0000
          Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-17 13:45 -0800
            Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-17 14:09 -0800
            Re: Dinamic array without malloc - Can be done? BartC <bc@freeuk.com> - 2017-01-17 22:41 +0000
            Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 15:06 -0800
              Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-17 16:49 -0800
              Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-17 16:56 -0800
                Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 20:37 -0800
                  Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-18 09:38 +0100
                  Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-31 08:49 -0800
                    Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-31 10:39 -0800
                      Re: Dinamic array without malloc - Can be done? luser droog <luser.droog@gmail.com> - 2017-01-31 10:55 -0800
                        Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-31 11:40 -0800
                      Re: Dinamic array without malloc - Can be done? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-31 10:57 -0800
                      Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-03 23:06 -0800
      Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 10:42 -0800
        Re: Dinamic array without malloc - Can be done? BartC <bc@freeuk.com> - 2017-01-15 20:15 +0000
          Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-15 12:43 -0800
          Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 15:08 -0800
    Re: Dinamic array without malloc - Can be done? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-15 12:25 -0500
      Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 10:46 -0800
        Re: Dinamic array without malloc - Can be done? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-15 20:13 +0000
          Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 15:06 -0800
      Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-15 12:46 -0800
        Re: Dinamic array without malloc - Can be done? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-15 16:10 -0500
        Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 20:37 -0800
          Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-15 21:02 -0800
            Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-30 04:23 -0800
          Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-16 09:05 +0100
            Re: Dinamic array without malloc - Can be done? Ian Collins <ian-news@hotmail.com> - 2017-01-16 21:16 +1300
              Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-16 09:48 +0100
    Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-15 09:29 -0800
      Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-15 09:37 -0800
      Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-15 09:56 -0800
        Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-15 10:34 -0800
      Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 10:48 -0800
        Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-15 11:10 -0800
        Re: Dinamic array without malloc - Can be done? Jean-Marc Bourguet <jm@bourguet.org> - 2017-01-15 20:22 +0100
          Re: Dinamic array without malloc - Can be done? Chad <cdalten@gmail.com> - 2017-01-15 11:50 -0800
          Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 15:12 -0800
    Re: Dinamic array without malloc - Can be done? Richard Heathfield <rjh@cpax.org.uk> - 2017-01-15 17:50 +0000
      Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 10:38 -0800
        Re: Dinamic array without malloc - Can be done? Richard Heathfield <rjh@cpax.org.uk> - 2017-01-15 19:34 +0000
          Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-15 12:51 -0800
            Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-15 13:10 -0800
              Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-15 16:23 -0800
                Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-15 18:08 -0800
              Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-16 09:56 +0100
                Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-16 08:35 -0800
                  Re: Dinamic array without malloc - Can be done? "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-16 11:07 -0800
                    Re: Dinamic array without malloc - Can be done? "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-16 11:17 -0800
                      Re: Dinamic array without malloc - Can be done? Robert Wessel <robertwessel2@yahoo.com> - 2017-01-16 15:21 -0600
                        Re: Dinamic array without malloc - Can be done? "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-31 22:22 -0800
                  Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-17 00:22 +0100
                    Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-16 16:23 -0800
                      Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-17 02:04 +0100
                        Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-16 17:27 -0800
                          Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-17 09:16 +0100
            Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 20:32 -0800
            Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-16 10:02 +0100
              Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-16 09:22 -0800
                Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-17 00:25 +0100
        Re: Dinamic array without malloc - Can be done? Barry Schwarz <schwarzb@dqel.com> - 2017-01-15 11:53 -0800
          Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-15 12:22 -0800
          Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 15:32 -0800
            Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-15 16:01 -0800
              Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-16 10:19 +0100
                Re: Dinamic array without malloc - Can be done? BartC <bc@freeuk.com> - 2017-01-16 11:28 +0000
                  Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-16 14:29 +0100
                    Re: Dinamic array without malloc - Can be done? BartC <bc@freeuk.com> - 2017-01-16 15:41 +0000
                      Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-16 17:27 +0100
                    Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-16 07:56 -0800
                      Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-16 17:31 +0100
                        Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-16 08:48 -0800
                          Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-17 00:29 +0100
                  Re: Dinamic array without malloc - Can be done? "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-16 11:25 -0800
                    Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-16 12:28 -0800
                      Re: Dinamic array without malloc - Can be done? "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-16 12:38 -0800
            Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-15 16:57 -0800
              Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-16 00:37 -0800
                Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-16 10:23 +0100
                  Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-16 01:35 -0800
                    Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-16 09:15 -0800
            Re: Dinamic array without malloc - Can be done? BartC <bc@freeuk.com> - 2017-01-16 01:29 +0000
          Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-16 10:08 +0100
            Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-16 08:08 -0800
              Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-17 00:35 +0100
                Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-16 16:31 -0800
                  Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-17 09:27 +0100
                    Re: Dinamic array without malloc - Can be done? BartC <bc@freeuk.com> - 2017-01-17 12:11 +0000
                      Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-17 14:23 +0100
                      Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 05:38 -0800
                        Re: Dinamic array without malloc - Can be done? BartC <bc@freeuk.com> - 2017-01-17 14:17 +0000
                          Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 07:09 -0800
                    Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 05:14 -0800
                      Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-17 14:40 +0100
                        Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 06:41 -0800
                          Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-17 16:00 +0100
                            Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 07:45 -0800
                              Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-17 08:18 -0800
                                Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-17 08:27 -0800
                                  Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 09:29 -0800
                                Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 09:23 -0800
                                  Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-17 10:35 -0800
                                    Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 12:41 -0800
                                      Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-17 13:45 -0800
                            Re: Dinamic array without malloc - Can be done? Robert Wessel <robertwessel2@yahoo.com> - 2017-01-17 21:00 -0600
        Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-15 11:55 -0800
        Re: Dinamic array without malloc - Can be done? Siri Cruise <chine.bleu@yahoo.com> - 2017-01-15 14:59 -0800
      Re: Dinamic array without malloc - Can be done? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-15 20:04 +0000
        Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-15 21:33 +0100
          Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-15 13:00 -0800
            Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 20:27 -0800
          Re: Dinamic array without malloc - Can be done? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-15 16:34 -0500
            Re: Dinamic array without malloc - Can be done? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-15 16:43 -0500
              Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-15 16:17 -0800
                Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 20:22 -0800
                  Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-15 21:00 -0800
                    Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-30 05:01 -0800
                      Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-30 11:35 -0800
                        Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-01 16:18 -0800
                          Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-02-01 16:37 -0800
                            Re: Dinamic array without malloc - Can be done? Robert Wessel <robertwessel2@yahoo.com> - 2017-02-01 23:21 -0600
                            Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-02 00:27 -0800
                              Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-02-02 10:58 -0800
                                Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-03 22:51 -0800
    Re: Dinamic array without malloc - Can be done? "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-15 15:41 -0800
      Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 15:44 -0800
        Re: Dinamic array without malloc - Can be done? "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-15 16:17 -0800
    Re: Dinamic array without malloc - Can be done? Alla _ <modelling.data@gmail.com> - 2017-01-16 01:47 -0800
      Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-16 01:50 -0800
        Re: Dinamic array without malloc - Can be done? Alla _ <modelling.data@gmail.com> - 2017-01-16 02:38 -0800
          Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-16 03:15 -0800
            Re: Dinamic array without malloc - Can be done? Alla _ <modelling.data@gmail.com> - 2017-01-16 03:40 -0800
              Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-16 04:21 -0800
            Re: Dinamic array without malloc - Can be done? Alla _ <modelling.data@gmail.com> - 2017-01-16 04:29 -0800
              Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-16 04:36 -0800
      Re: Dinamic array without malloc - Can be done? Richard Heathfield <rjh@cpax.org.uk> - 2017-01-16 11:36 +0000
        Re: Dinamic array without malloc - Can be done? Alla _ <modelling.data@gmail.com> - 2017-01-16 03:44 -0800
        Re: Dinamic array without malloc - Can be done? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-16 15:34 +0000
          Re: Dinamic array without malloc - Can be done? Richard Heathfield <rjh@cpax.org.uk> - 2017-01-16 16:01 +0000
    Re: Dinamic array without malloc - Can be done? John Bode <jfbode1029@gmail.com> - 2017-01-17 10:14 -0800
      Re: Dinamic array without malloc - Can be done? James Kuyper <jameskuyper@verizon.net> - 2017-01-17 13:21 -0500
        Re: Dinamic array without malloc - Can be done? John Bode <jfbode1029@gmail.com> - 2017-01-17 11:43 -0800
          Re: Dinamic array without malloc - Can be done? James Kuyper <jameskuyper@verizon.net> - 2017-01-17 15:07 -0500
        Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 12:24 -0800
      Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-17 10:24 -0800
      Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-30 05:21 -0800

Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8  Next page →

#102026

On 17/01/17 02:27, supercat@casperkitty.com wrote:
> On Monday, January 16, 2017 at 7:04:40 PM UTC-6, David Brown wrote:
>> I see what you mean.  I suspect the compiler can make some optimisations 
>> in such code if it knows it is safe to free the alloca space, but it 
>> probably can't do that here.
> 
> The compiler could only optimize if it knew how the called function would use
> the pointer.  Otherwise, if the code didn't explicitly free the alloca()
> storage a compiler would have to assume that any called function it couldn't
> see into might save a copy of the passed-in pointer, thus allowing it to be
> reused during the execution of any other opaque function that gets called
> prior to the return of the function calling alloca().

Correct.

>  
>> But just use VLA's.  They are deallocated at the end of their scope.
> 
> Their semantics aren't as bad as a free-less alloca(), but some uses of
> temporary storage would require lifetimes that don't line up very well with
> code block structures.  For example, parsers may benefit from being able to
> use a logical stack to keep track of nested structures without having to use
> recursive function calls.
> 

The world is not perfect.

I have already said why I think a "freea()" function would be a bad
idea, and I have not changed my mind.  I can agree that it might make a
few kinds of functions slightly neater or more efficient if it existed,
but I don't see it being worth the disadvantages.

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

#101912

Keith Thompson <kst-u@mib.org> writes:

> 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.  [...]

Isn't any call to alloca() undefined behavior, in the sense that
the Standard uses the term, no matter how much (or how little)
memory is asked for?

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

#101936

On 15/01/17 21:51, Keith Thompson wrote:
> 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.

Stack overflow can occur in many ways - local arrays (VLA or constant
size) is perhaps a common one, but uncontrolled recursion is probably
high on the list.  You can also get a stack overflow with just one
function call too many, or one local variable too many - that may be
rare on big machines, but it does happen in small embedded systems.  And
stack overflow behaviour is undefined in the C standards, and even if
you have an OS or hardware that defines the behaviour, the definition is
usually "something bad happens" !

IMHO, alloca and VLA are no worse than many other things in C - you
simply have to know what you are doing and be sure you are doing things
properly, such as checking the size before allocation.

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

That makes it different from (most) other functions, but I doubt if it
is going to be an issue in practice.  Alloca is certainly a somewhat
special function.

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

#101988

David Brown <david.brown@hesbynett.no> writes:
[...]
> IMHO, alloca and VLA are no worse than many other things in C - you
> simply have to know what you are doing and be sure you are doing things
> properly, such as checking the size before allocation.
[...]

I agree, mostly.  But alloca and VLAs make it easier (relative to
fixed-size arrays) to overflow the stack by accidentally allocating a
very large chunk of memory.  Given:

    {
        size_t n = some_computation;
        double vla[n];
    }

it can be arbitrarily difficult to avoid overflow, and to perform static
analysis of how much the stack can grow.

The solution, as with most things, is "be careful".

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

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

#102010

On 16/01/17 18:22, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> IMHO, alloca and VLA are no worse than many other things in C - you
>> simply have to know what you are doing and be sure you are doing things
>> properly, such as checking the size before allocation.
> [...]
>
> I agree, mostly.  But alloca and VLAs make it easier (relative to
> fixed-size arrays) to overflow the stack by accidentally allocating a
> very large chunk of memory.  Given:
>
>     {
>         size_t n = some_computation;
>         double vla[n];
>     }
>
> it can be arbitrarily difficult to avoid overflow, and to perform static
> analysis of how much the stack can grow.

Certainly it is easier to overflow the stack when using a feature that 
lets you make big allocations.  But you would never write:

	{
		size_t n = some_computation;
		char* p = malloc(n);
	}

without knowing about some_computation and its limits.  The same applies 
to alloca or VLA's - the difference is that you might want to be sure 
your limits are below 1 MB or so for VLA's, while you might be happy 
with GB limits for your malloc's.  But the principle is the same.

>
> The solution, as with most things, is "be careful".
>

We've got to earn our living somehow!

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

#101870

On Sun, 15 Jan 2017 10:38:17 -0800 (PST), "Fernando D. Bozzo"
<fdbozzo@gmail.com> wrote:

>El domingo, 15 de enero de 2017, 18:50:39 (UTC+1), Richard Heathfield  escribió:
><snip> 
>> Why don't you want to use malloc?
>> 
>
>
>Hi Richard, the reason is just to simplify the garbage collection automatically, and not needing to 
>free() manually at some point. If I could use some mechanism like try/catch then this could not be 
>a problem, but without it it makes more difficult to manage the flow of a program.
>
>May be is the little practice I have until now, but for small arrays (<1MB) could be a good idea.

Why do you think the garbage collection performed when the VLA is
destroyed is any simpler then the garbage collection performed when
allocated memory is freed?  Are you aware that you cannot extend (or
shrink) a VLA while the size of an allocated array can be adjusted by
realloc?

Since the "stack" is usually smaller than the "heap", using a VLA in a
recursive function can lead to problems sooner than using malloc.

I am curious how the choice of allocation method can affect the flow
of your program.  Could you give an example.  I realize that one
approach calls malloc which is outside your code.  But I'm pretty
certain the code generated by the definition of the VLA will do a lot
of processing unrelated to any executable statements you have coded.
It may even call malloc for you.

The frequently cited quote about premature optimization springs
unbidden to mind.

-- 
Remove del for email

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

#101877

W dniu niedziela, 15 stycznia 2017 20:53:40 UTC+1 użytkownik Barry Schwarz napisał:
> On Sun, 15 Jan 2017 10:38:17 -0800 (PST), "Fernando D. Bozzo"
> <fdbozzo@gmail.com> wrote:
> 
> >El domingo, 15 de enero de 2017, 18:50:39 (UTC+1), Richard Heathfield  escribió:
> ><snip> 
> >> Why don't you want to use malloc?
> >> 
> >
> >
> >Hi Richard, the reason is just to simplify the garbage collection automatically, and not needing to 
> >free() manually at some point. If I could use some mechanism like try/catch then this could not be 
> >a problem, but without it it makes more difficult to manage the flow of a program.
> >
> >May be is the little practice I have until now, but for small arrays (<1MB) could be a good idea.
> 
> Why do you think the garbage collection performed when the VLA is
> destroyed is any simpler then the garbage collection performed when
> allocated memory is freed?  Are you aware that you cannot extend (or
> shrink) a VLA while the size of an allocated array can be adjusted by
> realloc?
> 
> Since the "stack" is usually smaller than the "heap", using a VLA in a
> recursive function can lead to problems sooner than using malloc.
> 
> I am curious how the choice of allocation method can affect the flow
> of your program.  Could you give an example.  I realize that one
> approach calls malloc which is outside your code.  But I'm pretty
> certain the code generated by the definition of the VLA will do a lot
> of processing unrelated to any executable statements you have coded.
> It may even call malloc for you.
> 
> The frequently cited quote about premature optimization springs
> unbidden to mind.
> 
wouldnt 

add esp, size

just work? (in reality it could be more sub but i say add for simplicity)

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

#101895

El domingo, 15 de enero de 2017, 20:53:40 (UTC+1), Barry Schwarz  escribió:
> On Sun, 15 Jan 2017 10:38:17 -0800 (PST), "Fernando D. Bozzo"
> wrote:
> 
> >El domingo, 15 de enero de 2017, 18:50:39 (UTC+1), Richard Heathfield  escribió:
> ><snip> 
> >> Why don't you want to use malloc?
> >> 
> >
> >
> >Hi Richard, the reason is just to simplify the garbage collection automatically, and not needing to 
> >free() manually at some point. If I could use some mechanism like try/catch then this could not be 
> >a problem, but without it it makes more difficult to manage the flow of a program.
> >
> >May be is the little practice I have until now, but for small arrays (<1MB) could be a good idea.
> 
> Why do you think the garbage collection performed when the VLA is
> destroyed is any simpler then the garbage collection performed when
> allocated memory is freed?  Are you aware that you cannot extend (or
> shrink) a VLA while the size of an allocated array can be adjusted by
> realloc?
> 
> Since the "stack" is usually smaller than the "heap", using a VLA in a
> recursive function can lead to problems sooner than using malloc.
> 
> I am curious how the choice of allocation method can affect the flow
> of your program.  Could you give an example.  I realize that one
> approach calls malloc which is outside your code.  But I'm pretty
> certain the code generated by the definition of the VLA will do a lot
> of processing unrelated to any executable statements you have coded.
> It may even call malloc for you.
> 
> The frequently cited quote about premature optimization springs
> unbidden to mind.
> 

Hi Barry, of course I can get more detail!

I'm doing a practice on which I have to "fix" a copy of apache 2.2 (http://httpd.apache.org/docs/2.2/mod/core.html) that have some methods taked out, and I must to reprogram them following some directions given in the course (validations and the like).

One of those methods is the "parse" method, that receives the input line that I need to parse, something like:

GET /public/cat.html HTTP/1.1


So the VLAs I'm using are to make some string operations on a copy of this line to get back into parts (command, path, file and Http version)

As you can see, the size of data is small, can't be more than a couple of 100s chars, and that's why I didn't want to use malloc. I reserve the use of dynamic memory for when I really need a big size, but for less than 8 MB I think that is a waste of time and make the modifications a little more complicated than what I need.

I have a long background in OOP which is very useful to understand the most on programming, but I'd never programmed at so low level... and I'm liking it :)

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

#101901

On Sunday, January 15, 2017 at 5:32:12 PM UTC-6, Fernando D. Bozzo wrote:
> One of those methods is the "parse" method, that receives the input line that I need to parse, something like:
> 
> GET /public/cat.html HTTP/1.1
> 
> 
> So the VLAs I'm using are to make some string operations on a copy of this line to get back into parts (command, path, file and Http version)
> 
> As you can see, the size of data is small, can't be more than a couple of 100s chars, and that's why I didn't want to use malloc. I reserve the use of dynamic memory for when I really need a big size, but for less than 8 MB I think that is a waste of time and make the modifications a little more complicated than what I need.

Unless a function is deeply nested or recursive, there isn't going to be
much difference between allocating objects that may take up to 200 bytes
on the stack, versus allocating exactly 200 bytes, unless the cases where
the nesting is deeper coincide with those where the objects are smaller.
I more common situations, the reverse would be the case (with larger
objects requiring more levels of recursion to process).

Using fixed-sized arrays is almost certainly going to be faster if
adequate stack space exists to handle the maximum sizes, and may well
end up having a lower worst-case stack space requirement as well.  On
some systems there may be good usage cases for VLAs, but the minimum
size to make VLA usage really worthwhile on some systems may be larger
than the size to make them blow up on others.

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

#101938

On 16/01/17 01:01, supercat@casperkitty.com wrote:
> On Sunday, January 15, 2017 at 5:32:12 PM UTC-6, Fernando D. Bozzo
> wrote:
>> One of those methods is the "parse" method, that receives the input
>> line that I need to parse, something like:
>> 
>> GET /public/cat.html HTTP/1.1
>> 
>> 
>> So the VLAs I'm using are to make some string operations on a copy
>> of this line to get back into parts (command, path, file and Http
>> version)
>> 
>> As you can see, the size of data is small, can't be more than a
>> couple of 100s chars, and that's why I didn't want to use malloc. I
>> reserve the use of dynamic memory for when I really need a big
>> size, but for less than 8 MB I think that is a waste of time and
>> make the modifications a little more complicated than what I need.
> 
> Unless a function is deeply nested or recursive, there isn't going to
> be much difference between allocating objects that may take up to 200
> bytes on the stack, versus allocating exactly 200 bytes, unless the
> cases where the nesting is deeper coincide with those where the
> objects are smaller. I more common situations, the reverse would be
> the case (with larger objects requiring more levels of recursion to
> process).
> 
> Using fixed-sized arrays is almost certainly going to be faster if 
> adequate stack space exists to handle the maximum sizes, and may
> well end up having a lower worst-case stack space requirement as
> well.  On some systems there may be good usage cases for VLAs, but
> the minimum size to make VLA usage really worthwhile on some systems
> may be larger than the size to make them blow up on others.
> 

That is simply nonsense.

It is rare that Fir posts anything the makes sense, but in this thread
he actually did so - allocating a local array on the stack is basically
nothing more than an adjustment of the stack pointer.  It does not
matter significantly whether that adjustment is of a fixed size known at
compile time, or a value calculated at run-time.

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

#101948

On 16/01/2017 09:19, David Brown wrote:
> On 16/01/17 01:01, supercat@casperkitty.com wrote:

>> Using fixed-sized arrays is almost certainly going to be faster if
>> adequate stack space exists to handle the maximum sizes, and may
>> well end up having a lower worst-case stack space requirement as
>> well.  On some systems there may be good usage cases for VLAs, but
>> the minimum size to make VLA usage really worthwhile on some systems
>> may be larger than the size to make them blow up on others.
>>
>
> That is simply nonsense.
>
> It is rare that Fir posts anything the makes sense, but in this thread
> he actually did so - allocating a local array on the stack is basically
> nothing more than an adjustment of the stack pointer.  It does not
> matter significantly whether that adjustment is of a fixed size known at
> compile time, or a value calculated at run-time.

But the adjustment isn't done at entry to a function with all the other 
fixed-size objects (or not at all if a conventional stack frame is not 
used).

It's done separately after executing some code (calculating the length 
of the array). If it's in a loop, it can mean deallocating the space, 
and then allocating a new offset, each time around.

Furthermore, on some implementations such as gcc on x86, it can mean 
calling a function (__chkstk_ms()) to check the allocation isn't so 
large that it exceeds the stack guard page. This is not needed if it 
knows the local array will not be a beyond a certain size (I think 4KB 
or less total stack allocation within a function).

-- 
Bartc

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

#101962

On 16/01/17 12:28, BartC wrote:
> On 16/01/2017 09:19, David Brown wrote:
>> On 16/01/17 01:01, supercat@casperkitty.com wrote:
> 
>>> Using fixed-sized arrays is almost certainly going to be faster if
>>> adequate stack space exists to handle the maximum sizes, and may
>>> well end up having a lower worst-case stack space requirement as
>>> well.  On some systems there may be good usage cases for VLAs, but
>>> the minimum size to make VLA usage really worthwhile on some systems
>>> may be larger than the size to make them blow up on others.
>>>
>>
>> That is simply nonsense.
>>
>> It is rare that Fir posts anything the makes sense, but in this thread
>> he actually did so - allocating a local array on the stack is basically
>> nothing more than an adjustment of the stack pointer.  It does not
>> matter significantly whether that adjustment is of a fixed size known at
>> compile time, or a value calculated at run-time.
> 
> But the adjustment isn't done at entry to a function with all the other
> fixed-size objects (or not at all if a conventional stack frame is not
> used).

Why do you think adjustment is done at entry to a function for
fixed-size objects?  Adjustment /may/ be done on entry, but it may be
done later.  For some targets, adjustment may be done as needed while
storing something on the stack (a "push" instruction).  If a function
has an "early exit" path as an alternative to another path that uses
more of a stack frame, then it might well postpone the allocation until
it was needed.  Modern compilers with inter-procedural optimisations
have long since lost the neat divisions of object-code "functions"
matching source-code functions.  There are many possibilities beyond the
simple case of "allocate everything at function entry".

And no matter where the stack adjustment is made, it is /still/ no more
than an instruction or two.

> 
> It's done separately after executing some code (calculating the length
> of the array). If it's in a loop, it can mean deallocating the space,
> and then allocating a new offset, each time around.

It could mean that, yes - though you would not normally allocated and
deallocate memory inside a fast loop.  But again, you are just adding or
subtracting a value to the stack pointer - a "call" to alloca or a
creation of a VLA is an extremely cheap operation.

> 
> Furthermore, on some implementations such as gcc on x86, it can mean
> calling a function (__chkstk_ms()) to check the allocation isn't so
> large that it exceeds the stack guard page. This is not needed if it
> knows the local array will not be a beyond a certain size (I think 4KB
> or less total stack allocation within a function).
> 

You mean "gcc on windows", not "gcc on x86".

Yes, it is possible that __chkstk_ms() might be called more times than
necessary with a VLA than it would with fixed-size allocations, because
the compiler may not know an upper bound on the size for the VLA.  It is
unlikely to be a big issue, because __chkstk_ms() is a fast function on
average.  And of course you can usually tell the compiler about the
limits for the VLA sizes (which you should know, to use them safely).

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

#101968

On 16/01/2017 13:29, David Brown wrote:
> On 16/01/17 12:28, BartC wrote:

>> But the adjustment isn't done at entry to a function with all the other
>> fixed-size objects (or not at all if a conventional stack frame is not
>> used).
>
> Why do you think adjustment is done at entry to a function for
> fixed-size objects?  Adjustment /may/ be done on entry, but it may be
> done later.

If that is a lot of code that has to be executed before the VLA size is 
determined, then it is reasonable to assume that any allocations for the 
local variables are involved are done separately. Whether the earlier 
allocations are done at the actual function entry point or not, or are 
not done at all, is just nit-picking on your part.

>> Furthermore, on some implementations such as gcc on x86, it can mean
>> calling a function (__chkstk_ms()) to check the allocation isn't so
>> large that it exceeds the stack guard page. This is not needed if it
>> knows the local array will not be a beyond a certain size (I think 4KB
>> or less total stack allocation within a function).
>>
>
> You mean "gcc on windows", not "gcc on x86".

Why wouldn't gcc not on Windows not use such a function? And why doesn't 
gcc use the same fast method on Windows?

(As I understand it, it allows Windows programs to commit a large stack 
size without needing to allocate the memory until needed. There is 
already a mechanism to grow the stack automatically if it increases by 
small increments, but not if it skips one or more VM pages. So how does 
gcc on Linux for example manage it? Or does it have to allocate the 
maximum stack size right from the start?)

> Yes, it is possible that __chkstk_ms() might be called more times than
> necessary with a VLA than it would with fixed-size allocations, because
> the compiler may not know an upper bound on the size for the VLA.  It is
> unlikely to be a big issue, because __chkstk_ms() is a fast function on
> average.

Nevertheless, it is an extra function call.

I create one benchmark which ran twice as fast with a fixed size array 
as using a VLA of the same size (I knew it was the same; the compiler 
didn't). On Linux however which apparently doesn't use chkstk, it was 
only 10% faster.

> And of course you can usually tell the compiler about the
> limits for the VLA sizes (which you should know, to use them safely).

You can't use them safely if you don't know what recursion depth is 
likely. BTW what does the compiler actually check the VLA size against 
the limits at runtime? If so this is no longer one or two instructions.

-- 
Bartc

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

#101974

On 16/01/17 16:41, BartC wrote:
> On 16/01/2017 13:29, David Brown wrote:
>> On 16/01/17 12:28, BartC wrote:
> 
>>> But the adjustment isn't done at entry to a function with all the other
>>> fixed-size objects (or not at all if a conventional stack frame is not
>>> used).
>>
>> Why do you think adjustment is done at entry to a function for
>> fixed-size objects?  Adjustment /may/ be done on entry, but it may be
>> done later.
> 
> If that is a lot of code that has to be executed before the VLA size is
> determined, then it is reasonable to assume that any allocations for the
> local variables are involved are done separately. Whether the earlier
> allocations are done at the actual function entry point or not, or are
> not done at all, is just nit-picking on your part.

/All/ considerations about when the allocation is done are nit-picking
with regard to the time spent (late allocation can be a good thing in
saving stack space overall).  The actual allocation on the stack is
pretty much "free", whether it is a VLA or a constant size allocation.

> 
>>> Furthermore, on some implementations such as gcc on x86, it can mean
>>> calling a function (__chkstk_ms()) to check the allocation isn't so
>>> large that it exceeds the stack guard page. This is not needed if it
>>> knows the local array will not be a beyond a certain size (I think 4KB
>>> or less total stack allocation within a function).
>>>
>>
>> You mean "gcc on windows", not "gcc on x86".
> 
> Why wouldn't gcc not on Windows not use such a function? And why doesn't
> gcc use the same fast method on Windows?

The function is only needed on Windows, where you only have a single
spare 4 KB or 8 KB virtual page beyond the current stack.  On Linux, you
have (by default) 8 MB virtual memory for the stack - it's all available
(modulo memory over-commit issues) for use when you want it.  In both
Linux and Windows you need to ask for a bigger stack if you want to
exceed the default limits (1 MB on Windows, 8 MB on Linux).

The clue here is in the name - __chkstk_ms - "check stack Microsoft".

> 
> (As I understand it, it allows Windows programs to commit a large stack
> size without needing to allocate the memory until needed. There is
> already a mechanism to grow the stack automatically if it increases by
> small increments, but not if it skips one or more VM pages. So how does
> gcc on Linux for example manage it? Or does it have to allocate the
> maximum stack size right from the start?)

On Windows, the system only allocates a single /virtual/ page beyond the
current stack end.  That gets a physical page when it is touched, and
another virtual page is allocated (up to a limit which I believe is 1 MB
on Windows - I guess a program can change that if it wants to).  If a
program tries to touch a stack page more than the next page down without
forcing the physical allocation for the pages along the way, you get a
fault.

On Linux, the system allocates 8 MB virtual space for the stack straight
away.  Physical pages are mapped whenever a virtual page is touched.

The Linux method is more efficient and saves having an equivalent of
__chkstk_ms calls, but it relies on overcommit to avoid wasting real memory.


> 
>> Yes, it is possible that __chkstk_ms() might be called more times than
>> necessary with a VLA than it would with fixed-size allocations, because
>> the compiler may not know an upper bound on the size for the VLA.  It is
>> unlikely to be a big issue, because __chkstk_ms() is a fast function on
>> average.
> 
> Nevertheless, it is an extra function call.

Yes, unless it can be inlined (it doesn't do much - just touches memory
every 4K or 8K until the the target size has been reached) and may not
be needed if the compiler knows a limit on the allocation size.

> 
> I create one benchmark which ran twice as fast with a fixed size array
> as using a VLA of the same size (I knew it was the same; the compiler
> didn't). On Linux however which apparently doesn't use chkstk, it was
> only 10% faster.

Without any more information, it is hard to guess the details here.

> 
>> And of course you can usually tell the compiler about the
>> limits for the VLA sizes (which you should know, to use them safely).
> 
> You can't use them safely if you don't know what recursion depth is
> likely. 

You can't use /any/ recursion safely unless you know the recursion
depth.  You can't use /any/ function calls, or any local variables,
safely unless you know you are not going to exceed the stack limits.
VLAs are no different from fixed size allocations here, except that you
might need to think a little more to be sure of your limits for VLAs.

> BTW what does the compiler actually check the VLA size against
> the limits at runtime? If so this is no longer one or two instructions.
> 

If a compiler implements stack size checking, then it probably does.  If
the compiler does not implement stack size checking, then it will not
check the size of VLAs.

gcc has a number of flags that can be used for tracing stack usage at
compile time or run time, if that is what you mean by "the" compiler.

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

#101969

On Monday, January 16, 2017 at 7:29:34 AM UTC-6, David Brown wrote:
> Why do you think adjustment is done at entry to a function for
> fixed-size objects?  Adjustment /may/ be done on entry, but it may be
> done later.  For some targets, adjustment may be done as needed while
> storing something on the stack (a "push" instruction).  If a function
> has an "early exit" path as an alternative to another path that uses
> more of a stack frame, then it might well postpone the allocation until
> it was needed.  Modern compilers with inter-procedural optimisations
> have long since lost the neat divisions of object-code "functions"
> matching source-code functions.  There are many possibilities beyond the
> simple case of "allocate everything at function entry".

On most platforms, allocating everything at function entry will be a
reasonably efficient approach that will be usable in all cases that don't
involve VLAs.  Other approaches may not be usable in all cases, but may be
more efficient in those cases where they are usable.

In the absence of variable length arrays, the worst-case cost for allocating
local variables would on many platforms be one instructions on entry and one
on exit if a frame pointer is not used, or three on entry and two on exit if
a frame pointer is used.  These costs are generally independent of the number
of variables to be allocated or their lifetimes.  While implementations may
create variables with shorter lifetimes in cases where that would improve
efficiency, they generally avoid doing anything that would be less efficient
than allocating space for all variables at function entry and cleaning them
all up at function exit.

In cases where a frame pointer would be needed with or without a VLA, the
cost of a block with a VLA might be as low as two instructions on entry and
one on exit, but in the more typical cases where a frame pointer wouldn't
be needed in the absence of a VLA, maintaining the frame pointer will cost
an extra two instructions on entry and one on exit.

As for telling the compiler about size limits for the VLA, how would one be
expected to go about that?

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

#101976

On 16/01/17 16:56, supercat@casperkitty.com wrote:
> On Monday, January 16, 2017 at 7:29:34 AM UTC-6, David Brown wrote:
>> Why do you think adjustment is done at entry to a function for
>> fixed-size objects?  Adjustment /may/ be done on entry, but it may be
>> done later.  For some targets, adjustment may be done as needed while
>> storing something on the stack (a "push" instruction).  If a function
>> has an "early exit" path as an alternative to another path that uses
>> more of a stack frame, then it might well postpone the allocation until
>> it was needed.  Modern compilers with inter-procedural optimisations
>> have long since lost the neat divisions of object-code "functions"
>> matching source-code functions.  There are many possibilities beyond the
>> simple case of "allocate everything at function entry".
> 
> On most platforms, allocating everything at function entry will be a
> reasonably efficient approach that will be usable in all cases that don't
> involve VLAs.  Other approaches may not be usable in all cases, but may be
> more efficient in those cases where they are usable.
> 
> In the absence of variable length arrays, the worst-case cost for allocating
> local variables would on many platforms be one instructions on entry and one
> on exit if a frame pointer is not used, or three on entry and two on exit if
> a frame pointer is used.  These costs are generally independent of the number
> of variables to be allocated or their lifetimes.  While implementations may
> create variables with shorter lifetimes in cases where that would improve
> efficiency, they generally avoid doing anything that would be less efficient
> than allocating space for all variables at function entry and cleaning them
> all up at function exit.

The reason a compiler might not allocate all of a function's possible
frame at the start is that different paths through the function may have
different stack usage.  If the function calls other functions, it is a
good thing if it avoids wasting stack space before making the next call.
 For small stack frames, this usually does not matter - for big frames,
it can be relevant and it is worth spending a few more instructions to
reduce the overall stack usage.

> 
> In cases where a frame pointer would be needed with or without a VLA, the
> cost of a block with a VLA might be as low as two instructions on entry and
> one on exit, but in the more typical cases where a frame pointer wouldn't
> be needed in the absence of a VLA, maintaining the frame pointer will cost
> an extra two instructions on entry and one on exit.
> 
> As for telling the compiler about size limits for the VLA, how would one be
> expected to go about that?
> 

	if (n >= 200) __builtin_unreachable();
	char a[n];

or

	if (n >= 200) return 0;
	char a[n];

or

	if (n >= 200) n = 200;
	char a[n];

or

	if (n >= 200) exit(1);
	char a[n];

Take your pick.

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

#101980

On Monday, January 16, 2017 at 10:31:23 AM UTC-6, David Brown wrote:
> > As for telling the compiler about size limits for the VLA, how would one be
> > expected to go about that?
> > 
> 
> 	if (n >= 200) __builtin_unreachable();
> 	char a[n];

That's the approach that's least likely to result in extra generated code,
but __builtin_unreachable() is a non-standard extension.

> 	if (n >= 200) return 0;
> 	char a[n];
> or
> 
> 	if (n >= 200) exit(1);
> 	char a[n];

If the function's specifications require defined behavior for out-of-range
values, a compiler might be able to use the bounds-check code to infer
a maximum array size.  If inputs could never actually get that large for
reasons the compiler doesn't know about, such constructs would force the
compiler to generate extra code.  Perhaps the cost of the useless extra code
might be less than the averted cost of code saved by letting the compiler
replace the char a[n] with char a[200], but that still doesn't seem like a
great approach.

> 	if (n >= 200) n = 200;
> 	char a[n];

Even if compilers would be allowed to skip the conditional check if they
treat the array as having a fixed size of 200, do you think many would
skip the check?

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

#102011

On 16/01/17 17:48, supercat@casperkitty.com wrote:
> On Monday, January 16, 2017 at 10:31:23 AM UTC-6, David Brown wrote:
>>> As for telling the compiler about size limits for the VLA, how would one be
>>> expected to go about that?
>>>
>>
>> 	if (n >= 200) __builtin_unreachable();
>> 	char a[n];
>
> That's the approach that's least likely to result in extra generated code,
> but __builtin_unreachable() is a non-standard extension.
>

Correct.  Compilers often have something equivalent - use a macro for 
portability, with a fall-back to "exit(1)" or something like that.

>> 	if (n >= 200) return 0;
>> 	char a[n];
>> or
>>
>> 	if (n >= 200) exit(1);
>> 	char a[n];
>
> If the function's specifications require defined behavior for out-of-range
> values, a compiler might be able to use the bounds-check code to infer
> a maximum array size.  If inputs could never actually get that large for
> reasons the compiler doesn't know about, such constructs would force the
> compiler to generate extra code.

A call to exit() is unlikely to use much code - a couple of 
instructions, perhaps.  And in cases where a couple of instructions is 
relevant, you are probably working on a small embedded system with a 
specific compiler, and a compiler-specific __builtin_unreachable() will 
be fine.

>  Perhaps the cost of the useless extra code
> might be less than the averted cost of code saved by letting the compiler
> replace the char a[n] with char a[200], but that still doesn't seem like a
> great approach.
>
>> 	if (n >= 200) n = 200;
>> 	char a[n];
>
> Even if compilers would be allowed to skip the conditional check if they
> treat the array as having a fixed size of 200, do you think many would
> skip the check?
>

I don't think compilers /would/ treat the array as having a fixed size 
of 200 - though I think they certainly /could/ do so and give correct 
code.  But using the fixed size would mean you miss out on the benefits 
of saving stack space, so it is unlikely that a compiler would do that.

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

#102000

On 1/16/2017 3:28 AM, BartC wrote:
> On 16/01/2017 09:19, David Brown wrote:
>> On 16/01/17 01:01, supercat@casperkitty.com wrote:
>
>>> Using fixed-sized arrays is almost certainly going to be faster if
>>> adequate stack space exists to handle the maximum sizes, and may
>>> well end up having a lower worst-case stack space requirement as
>>> well.  On some systems there may be good usage cases for VLAs, but
>>> the minimum size to make VLA usage really worthwhile on some systems
>>> may be larger than the size to make them blow up on others.
>>>
>>
>> That is simply nonsense.
>>
>> It is rare that Fir posts anything the makes sense, but in this thread
>> he actually did so - allocating a local array on the stack is basically
>> nothing more than an adjustment of the stack pointer.  It does not
>> matter significantly whether that adjustment is of a fixed size known at
>> compile time, or a value calculated at run-time.
>
> But the adjustment isn't done at entry to a function with all the other
> fixed-size objects (or not at all if a conventional stack frame is not
> used).
>
> It's done separately after executing some code (calculating the length
> of the array). If it's in a loop, it can mean deallocating the space,
> and then allocating a new offset, each time around.

Deallocating the "some" space and atomically realigning the pointers.

Wow, this reminds me of when I was programming servers in winnt using 
IOCP. Re/deallocating wrt going into dropping "slow/timedout 
connections" in panic mode wrt too many clients, (back then I could 
handle around 60,000 loaded and live (active) connections) on winnt.

Actually, this brings back a database like mutex based technique that 
can atomically lock multiple records/objects, at once, akin to lock 
based transactional memory IIRC, the deadlock avoiding locking pattern 
can be outfitted with rwlocks instead of mutex...


>
> Furthermore, on some implementations such as gcc on x86, it can mean
> calling a function (__chkstk_ms()) to check the allocation isn't so
> large that it exceeds the stack guard page. This is not needed if it
> knows the local array will not be a beyond a certain size (I think 4KB
> or less total stack allocation within a function).
>

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

#102004

On Monday, January 16, 2017 at 1:25:21 PM UTC-6, Chris M. Thomasson wrote:
> Actually, this brings back a database like mutex based technique that 
> can atomically lock multiple records/objects, at once, akin to lock 
> based transactional memory IIRC, the deadlock avoiding locking pattern 
> can be outfitted with rwlocks instead of mutex...

If two threads tried to use the same LIFO memory manager and one thread
were holding some LIFO-managed storage when the second thread acquired
some of its own, the first thread would not be able to release its
storage until the second thread released its storage.  Not a particularly
nice arrangement.

A much better arrangement would be for each thread to have its own
independent LIFO memory manager.  Provided that the system supported
some efficient means of declaring "thread-static" variables, such an
approach would eliminate the need for any kind of locking or other
coordination.

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

Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8  Next page →

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

csiph-web