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 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8  Next page →

#101865

"Fernando D. Bozzo" <fdbozzo@gmail.com> writes:

> El domingo, 15 de enero de 2017, 18:29:39 (UTC+1), fir  escribió:
> <snip> 
>> > 
>> it is also possible that when you declare big static 
>> array like
>> 
>> char table[200*1024*1024];
>> 
>> some systems (like windows) will only attach physical memory 'on touch' i mean if you will be using only 
>> first 10% of it rest will not really be physically 
>> allocked/consumed
>> (sadly i dont know the details (best would be to get practical method of checking which pages are allocked 
>> and which adress space is hanging unattached)
>
>
> I'm trying to stay between the size of the stack (I think it's 8 MB? on Ubuntu), so I never use large arrays with this VLAs.

You can change it with ulimit and change the default in
/etc/security/limits.conf.

The true reason for avoiding big stack usage is when you start to do
multi-thread programming.  Each thread has its stack and allowing it's
difficult to allocate them if they have to be huge. (BTW, their size is
controlled in another way)

Yours,

-- 
Jean-Marc

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

#101869

On Sunday, January 15, 2017 at 11:22:59 AM UTC-8, Jean-Marc Bourguet wrote:
> "Fernando D. Bozzo" <fdbozzo@gmail.com> writes:
> 
> > El domingo, 15 de enero de 2017, 18:29:39 (UTC+1), fir  escribió:
> > <snip> 
> >> > 
> >> it is also possible that when you declare big static 
> >> array like
> >> 
> >> char table[200*1024*1024];
> >> 
> >> some systems (like windows) will only attach physical memory 'on touch' i mean if you will be using only 
> >> first 10% of it rest will not really be physically 
> >> allocked/consumed
> >> (sadly i dont know the details (best would be to get practical method of checking which pages are allocked 
> >> and which adress space is hanging unattached)
> >
> >
> > I'm trying to stay between the size of the stack (I think it's 8 MB? on Ubuntu), so I never use large arrays with this VLAs.
> 
> You can change it with ulimit and change the default in
> /etc/security/limits.conf.
> 
> The true reason for avoiding big stack usage is when you start to do
> multi-thread programming.  Each thread has its stack and allowing it's
> difficult to allocate them if they have to be huge. (BTW, their size is
> controlled in another way)
> 

firs is a wannabe programmer who only stick to MS Windows.

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

#101892

El domingo, 15 de enero de 2017, 20:22:59 (UTC+1), Jean-Marc Bourguet  escribió:
> "Fernando D. Bozzo" writes:
> 
> > El domingo, 15 de enero de 2017, 18:29:39 (UTC+1), fir  escribió:
> > <snip> 
> >> > 
> >> it is also possible that when you declare big static 
> >> array like
> >> 
> >> char table[200*1024*1024];
> >> 
> >> some systems (like windows) will only attach physical memory 'on touch' i mean if you will be using only 
> >> first 10% of it rest will not really be physically 
> >> allocked/consumed
> >> (sadly i dont know the details (best would be to get practical method of checking which pages are allocked 
> >> and which adress space is hanging unattached)
> >
> >
> > I'm trying to stay between the size of the stack (I think it's 8 MB? on Ubuntu), so I never use large arrays with this VLAs.
> 
> You can change it with ulimit and change the default in
> /etc/security/limits.conf.
> 
> The true reason for avoiding big stack usage is when you start to do
> multi-thread programming.  Each thread has its stack and allowing it's
> difficult to allocate them if they have to be huge. (BTW, their size is
> controlled in another way)
> 
> Yours,
> 
> -- 
> Jean-Marc

Thanks Jean for the tip.-

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

#101855

On 15/01/17 16:45, Fernando D. Bozzo wrote:
> From the beginning of my course I'm looking a way to define an array
> with a number of elements based on some other variable which I don't
> know, but without using the dynamic memory space (with malloc)

My preference here would be to use malloc.

Nevertheless, from C99 onwards you can use variable-length arrays.

> len = (some calculated length that can vary in every execution);
> char myArray[len];

That looks like legal C99 to me.

> I've tryied this way, but didn't compile. My aim is not needing to
> free() it later, but that this array get cleared as all other auto
> variables.

Then you may not have a C99 compiler.

Why don't you want to use malloc?

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#101859

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.

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

#101867

On 15/01/17 18:38, 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.

Okay. (Personally, I don't find this to be a big deal.)

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

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.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

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

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

#101885

On Sunday, January 15, 2017 at 2:51:04 PM UTC-6, Keith Thompson wrote:
> alloca() is neither ISO C nor POSIX, though it's supported on a lot of
> Unix-like systems.

The alloca() macro/intrinsic/whatever has poorly-defined semantics which
severely limit the situations where it can be used safely.  Things would
have been much better if there had been a corresponding freea() intrinsic,
and code was required to freea() blocks in reverse order of allocation,
and before a function returned.  Since an implementation could have
achieved the required semantics simply by aliasing alloca() and freea()
to malloc() and free(), though doing so would forego potentially-useful
optimizations].  As it is, alloca() was a hack that was easy to implement
with some compilers, but would require a lot more work to implement
usefully on others.

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

#101904

supercat@casperkitty.com writes:
> On Sunday, January 15, 2017 at 2:51:04 PM UTC-6, Keith Thompson wrote:
>> alloca() is neither ISO C nor POSIX, though it's supported on a lot of
>> Unix-like systems.
>
> The alloca() macro/intrinsic/whatever has poorly-defined semantics which
> severely limit the situations where it can be used safely.  Things would
> have been much better if there had been a corresponding freea() intrinsic,
> and code was required to freea() blocks in reverse order of allocation,
> and before a function returned.  Since an implementation could have
> achieved the required semantics simply by aliasing alloca() and freea()
> to malloc() and free(), though doing so would forego potentially-useful
> optimizations].  As it is, alloca() was a hack that was easy to implement
> with some compilers, but would require a lot more work to implement
> usefully on others.

The whole point of alloca() is that you don't have to deallocate the
memory.  Requiring freea() calls in a particular order would defeat that
purpose.  What happens if a program doesn't call freea()?

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

#101908

On Sunday, January 15, 2017 at 6:22:07 PM UTC-6, Keith Thompson wrote:
> The whole point of alloca() is that you don't have to deallocate the
> memory.  Requiring freea() calls in a particular order would defeat that
> purpose.  What happens if a program doesn't call freea()?

That's a pretty useless advantage compared with the speed boost on
some implementations compared with malloc/free.

Implementations may promise to automatically release the storage, and
it would be helpful to have a standard macro to indicate that promise,
but code which balanced calls to alloca() and freea() could be more
easily adapted to existing implementations than code which required
the compiler to perform an automatic freeing operation.

Absent a promise, returning from a function without freeing the storage
would invoke UB.

The semantics of setjmp/longjmp would be a bit more complicated, but
could be resolved cleanly with a marka/rewinda pair with the semantics
that marka would return an opaque object, and invoking rewinda upon that
object would deallocate everything that was alloca'ed since it was marked.
An implementation could promise that setjmp/longjmp would automatically
free up anything that had been alloca'ed but for implementations that did
not do so code would have to either limit use of alloca between setjmp
and longjmp, or else bracket the call and "return through" setjmp with
calls to marka and rewinda.  While it would be desirable to have
implementations take care of that automatically, some implementations may
not be able to do so without breaking ABI compatibility with other code
using setjmp/longjmp.

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

#101935

On 15/01/17 22:10, supercat@casperkitty.com wrote:
> On Sunday, January 15, 2017 at 2:51:04 PM UTC-6, Keith Thompson wrote:
>> alloca() is neither ISO C nor POSIX, though it's supported on a lot of
>> Unix-like systems.
> 
> The alloca() macro/intrinsic/whatever has poorly-defined semantics which
> severely limit the situations where it can be used safely.  Things would
> have been much better if there had been a corresponding freea() intrinsic,
> and code was required to freea() blocks in reverse order of allocation,
> and before a function returned.  Since an implementation could have
> achieved the required semantics simply by aliasing alloca() and freea()
> to malloc() and free(), though doing so would forego potentially-useful
> optimizations].  As it is, alloca() was a hack that was easy to implement
> with some compilers, but would require a lot more work to implement
> usefully on others.
> 

alloca (and VLAs) has three key advantages over malloc.  First, it is
fast.  Secondly, it is as space-efficient as possible.  Thirdly, you
don't need to deallocate it - it is automatically deallocated at the end
of the block.  A key /disadvantage/ is that you don't have the
flexibility to re-order your allocations and deallocations - this is
strictly stack ordering.

By having a "freea()" function, you would lose the benefit of automatic
deallocation.  And unless your freea() function were to be completely
useless, you would need to deal with varied orders of alloca() and
freea().  That means tracking allocations - leading to ram space and
time overhead, as well as code space, not unlike malloc().

Basically, your idea would completely spoil the whole point of alloca()
and give you something not much faster than malloc(), while being far
less flexible.

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

#101977

On Monday, January 16, 2017 at 2:56:27 AM UTC-6, David Brown wrote:
> alloca (and VLAs) has three key advantages over malloc.  First, it is
> fast.  Secondly, it is as space-efficient as possible.  Thirdly, you
> don't need to deallocate it - it is automatically deallocated at the end
> of the block.  A key /disadvantage/ is that you don't have the
> flexibility to re-order your allocations and deallocations - this is
> strictly stack ordering.

A bigger disadvantage is that it is unusable even in many cases where stack
ordering would be fine.  If a loop needed to create a temporary variable-
length object whose length is computed within the loop, that could easily
be handled with alloca/freea; the only way to accomplish that without a
freea() intrinsic is to move the inside of the loop into another function
and prevent the compiler from inlining it.  Even with the added cost of a
function call that approach would likely be cheaper than using malloc/free,
but it would be rather brittle.  Further, if the compiler decides to inline
the function stack use could easily skyrocket.

> By having a "freea()" function, you would lose the benefit of automatic
> deallocation.  And unless your freea() function were to be completely
> useless, you would need to deal with varied orders of alloca() and
> freea().  That means tracking allocations - leading to ram space and
> time overhead, as well as code space, not unlike malloc().

Implementations that support alloca() typically reserve two registers for
use as a stack pointer and frame pointer.  On entry to each function that
uses alloca(), the compiler generates:

    *((unsigned char*)__stack_pointer) = frame_pointer;
    __stack_pointer -= sizeof frame_pointer;
    __frame_pointer = __stack_pointer;

and on exit the compiler generates:

    __stack_pointer = frame_pointer;

The alloc intrinsic is simply:

    void *temp = __stack_pointer;
    __stack_pointer -= [[alignment-adjusted size]];
    return temp;

If the __freea() intrinsic accepted arguments for the pointer and size, then
it could on frame-pointer-based implementations be processed as simply:

    __stack_pointer += [[alignment-adjusted size]];

In many cases, pre-existing logic to deal with multiple consecutive writes
to the same register would be able to eliminate even the minimal cost of
freea().  Further, if a compiler knew that all calls to the allocate and
free intrinsics were balanced, it could in many cases eliminate the code
that would be required to save and restore the frame pointer.

> Basically, your idea would completely spoil the whole point of alloca()
> and give you something not much faster than malloc(), while being far
> less flexible.

To the contrary, it would provide a feature which would often have less
overhead than alloca() while being far more flexible, and also allowing
code using it to be usable on more machines, if not all [on some platforms
it may be expensive to guarantee the behavior in cases where code performs
a setjmp(), alloca(), and longjmp(), without having freed up the temporary
allocation first; if support for that usage case was optional, code which
used balanced pair of stack-allocate/stack-free functions could be run
without changes on any platform.  Further, even platforms that would normally
do the allocations on the stack could easily provide an option to use the
heap instead if the required object sizes grew large enough that the stack
was no longer usable.  Adapting code which uses alloca() without a freeing
function would be much more difficult.

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

#101998

On 1/16/2017 8:35 AM, supercat@casperkitty.com wrote:
> On Monday, January 16, 2017 at 2:56:27 AM UTC-6, David Brown wrote:
>> alloca (and VLAs) has three key advantages over malloc.  First, it is
>> fast.  Secondly, it is as space-efficient as possible.  Thirdly, you
>> don't need to deallocate it - it is automatically deallocated at the end
>> of the block.  A key /disadvantage/ is that you don't have the
>> flexibility to re-order your allocations and deallocations - this is
>> strictly stack ordering.
>
> A bigger disadvantage is that it is unusable even in many cases where stack
> ordering would be fine.  If a loop needed to create a temporary variable-
> length object whose length is computed within the loop, that could easily
> be handled with alloca/freea; the only way to accomplish that without a
> freea() intrinsic is to move the inside of the loop into another function
> and prevent the compiler from inlining it.  Even with the added cost of a
> function call that approach would likely be cheaper than using malloc/free,
> but it would be rather brittle.  Further, if the compiler decides to inline
> the function stack use could easily skyrocket.
>
>> By having a "freea()" function, you would lose the benefit of automatic
>> deallocation.  And unless your freea() function were to be completely
>> useless, you would need to deal with varied orders of alloca() and
>> freea().  That means tracking allocations - leading to ram space and
>> time overhead, as well as code space, not unlike malloc().
>
> Implementations that support alloca() typically reserve two registers for
> use as a stack pointer and frame pointer.  On entry to each function that
> uses alloca(), the compiler generates:
>
>     *((unsigned char*)__stack_pointer) = frame_pointer;
>     __stack_pointer -= sizeof frame_pointer;
>     __frame_pointer = __stack_pointer;
>
> and on exit the compiler generates:
>
>     __stack_pointer = frame_pointer;
>
> The alloc intrinsic is simply:
>
>     void *temp = __stack_pointer;
>     __stack_pointer -= [[alignment-adjusted size]];
>     return temp;
>
> If the __freea() intrinsic accepted arguments for the pointer and size, then
> it could on frame-pointer-based implementations be processed as simply:
>
>     __stack_pointer += [[alignment-adjusted size]];
>
> In many cases, pre-existing logic to deal with multiple consecutive writes
> to the same register would be able to eliminate even the minimal cost of
> freea().  Further, if a compiler knew that all calls to the allocate and
> free intrinsics were balanced, it could in many cases eliminate the code
> that would be required to save and restore the frame pointer.
>
>> Basically, your idea would completely spoil the whole point of alloca()
>> and give you something not much faster than malloc(), while being far
>> less flexible.
[...]

FWIW, I remember using alloca to pad thread local storage in 
hyperthreaded intel processors a while back. I will try to find the code.

IIRC, there was a problem wrt threads stacks interfering with each other 
(false sharing) in hyper thread setup. alloca would "fix" the problem by 
moving them apart such that the deadly sharing on per-thread contexts 
could be avoided.

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

#101999

On 1/16/2017 11:07 AM, Chris M. Thomasson wrote:
> On 1/16/2017 8:35 AM, supercat@casperkitty.com wrote:
[...]
> FWIW, I remember using alloca to pad thread local storage in
> hyperthreaded intel processors a while back. I will try to find the code.
>
> IIRC, there was a problem wrt threads stacks interfering with each other
> (false sharing) in hyper thread setup. alloca would "fix" the problem by
> moving them apart such that the deadly sharing on per-thread contexts
> could be avoided.

Fwiw, here is the code:

http://webpages.charter.net/appcore/appcore/src/ac_thread_c.html

If interested at all, please take a look at the following function:

(notice the call to alloca?)
____________________________________________
void* AC_CDECL
prv_thread_entry
( void *state )
{
   int ret;
   void *uret;
   ac_thread_t *_this = state;

   ret = pthread_setspecific
           ( g_tls_key,
             _this );
   if ( ret ) { assert( ! ret ); abort(); }

   if ( _this->id < 64 )
   {
     AC_OS_ALLOCA( 2048 * _this->id );
     uret = _this->fp_entry( (void*)_this->state );
   }

   else
   {
     uret = _this->fp_entry( (void*)_this->state );
   }

   return uret;
}
____________________________________________

IIRC, this hardcore alloca hack-around-the-problem, was suggested to me 
by an Intel paper that I cannot seem to find right now. I remember 
reading it, wrt the fact that they noticed the sharing problem in early 
hyperthreaded processors, and this alloca hack-in-the-box thing "fixes 
it". Heck IIRC, I used the extra space in alloca to store some static 
things that did not mind being destroyed at scope end.

Ahh hell, this was back in 2005, using msvc 6.0 and its crazy dinkumware 
and nasty c++ template oddities.

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

#102006

On Mon, 16 Jan 2017 11:17:03 -0800, "Chris M. Thomasson"
<invalid@invalid.invalid> wrote:

>On 1/16/2017 11:07 AM, Chris M. Thomasson wrote:
>> On 1/16/2017 8:35 AM, supercat@casperkitty.com wrote:
>[...]
>> FWIW, I remember using alloca to pad thread local storage in
>> hyperthreaded intel processors a while back. I will try to find the code.
>>
>> IIRC, there was a problem wrt threads stacks interfering with each other
>> (false sharing) in hyper thread setup. alloca would "fix" the problem by
>> moving them apart such that the deadly sharing on per-thread contexts
>> could be avoided.
>
>Fwiw, here is the code:
>
>http://webpages.charter.net/appcore/appcore/src/ac_thread_c.html
>
>If interested at all, please take a look at the following function:
>
>(notice the call to alloca?)
>____________________________________________
>void* AC_CDECL
>prv_thread_entry
>( void *state )
>{
>   int ret;
>   void *uret;
>   ac_thread_t *_this = state;
>
>   ret = pthread_setspecific
>           ( g_tls_key,
>             _this );
>   if ( ret ) { assert( ! ret ); abort(); }
>
>   if ( _this->id < 64 )
>   {
>     AC_OS_ALLOCA( 2048 * _this->id );
>     uret = _this->fp_entry( (void*)_this->state );
>   }
>
>   else
>   {
>     uret = _this->fp_entry( (void*)_this->state );
>   }
>
>   return uret;
>}
>____________________________________________
>
>IIRC, this hardcore alloca hack-around-the-problem, was suggested to me 
>by an Intel paper that I cannot seem to find right now. I remember 
>reading it, wrt the fact that they noticed the sharing problem in early 
>hyperthreaded processors, and this alloca hack-in-the-box thing "fixes 
>it". Heck IIRC, I used the extra space in alloca to store some static 
>things that did not mind being destroyed at scope end.
>
>Ahh hell, this was back in 2005, using msvc 6.0 and its crazy dinkumware 
>and nasty c++ template oddities.


That sounds like the old P4 64KB aliasing issue.  Basically the cache
design allowed/caused excessive conflicts if data items were exactly a
multiple of 64KB apart.  This had nothing in particular to do with
hyperthreading, although if you had two threads running simultaneously
with stacks aligned the "right" way (not uncommon, given how many OS's
allocate stack address space), you'd hit that aliasing issue, and
cause cache thrashing (since the two threads on the one core share the
same cache).

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

#102894

On 1/16/2017 1:21 PM, Robert Wessel wrote:
> On Mon, 16 Jan 2017 11:17:03 -0800, "Chris M. Thomasson"
> <invalid@invalid.invalid> wrote:
>
>> On 1/16/2017 11:07 AM, Chris M. Thomasson wrote:
>>> On 1/16/2017 8:35 AM, supercat@casperkitty.com wrote:
>> [...]
>>> FWIW, I remember using alloca to pad thread local storage in
>>> hyperthreaded intel processors a while back. I will try to find the code.
>>>
>>> IIRC, there was a problem wrt threads stacks interfering with each other
>>> (false sharing) in hyper thread setup. alloca would "fix" the problem by
>>> moving them apart such that the deadly sharing on per-thread contexts
>>> could be avoided.
>>
>> Fwiw, here is the code:
>>
>> http://webpages.charter.net/appcore/appcore/src/ac_thread_c.html
>>
>> If interested at all, please take a look at the following function:
>>
>> (notice the call to alloca?)
>> ____________________________________________
>> void* AC_CDECL
>> prv_thread_entry
>> ( void *state )
>> {
>>   int ret;
>>   void *uret;
>>   ac_thread_t *_this = state;
>>
>>   ret = pthread_setspecific
>>           ( g_tls_key,
>>             _this );
>>   if ( ret ) { assert( ! ret ); abort(); }
>>
>>   if ( _this->id < 64 )
>>   {
>>     AC_OS_ALLOCA( 2048 * _this->id );
>>     uret = _this->fp_entry( (void*)_this->state );
>>   }
>>
>>   else
>>   {
>>     uret = _this->fp_entry( (void*)_this->state );
>>   }
>>
>>   return uret;
>> }
>> ____________________________________________
>>
>> IIRC, this hardcore alloca hack-around-the-problem, was suggested to me
>> by an Intel paper that I cannot seem to find right now. I remember
>> reading it, wrt the fact that they noticed the sharing problem in early
>> hyperthreaded processors, and this alloca hack-in-the-box thing "fixes
>> it". Heck IIRC, I used the extra space in alloca to store some static
>> things that did not mind being destroyed at scope end.
>>
>> Ahh hell, this was back in 2005, using msvc 6.0 and its crazy dinkumware
>> and nasty c++ template oddities.
>
>
> That sounds like the old P4 64KB aliasing issue.  Basically the cache
> design allowed/caused excessive conflicts if data items were exactly a
> multiple of 64KB apart.  This had nothing in particular to do with
> hyperthreading, although if you had two threads running simultaneously
> with stacks aligned the "right" way (not uncommon, given how many OS's
> allocate stack address space), you'd hit that aliasing issue, and
> cause cache thrashing (since the two threads on the one core share the
> same cache).
>

Exactly! IIRC, the paper showed something like expanding the thread 
stacks, such that they avoided conflicting with each other wrt good code 
that avoids false-sharing, by multiplying them, a threads stack offset, 
by a reasonable thread id.

;^D

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

#102008

On 16/01/17 17:35, supercat@casperkitty.com wrote:
> On Monday, January 16, 2017 at 2:56:27 AM UTC-6, David Brown wrote:
>> alloca (and VLAs) has three key advantages over malloc.  First, it is
>> fast.  Secondly, it is as space-efficient as possible.  Thirdly, you
>> don't need to deallocate it - it is automatically deallocated at the end
>> of the block.  A key /disadvantage/ is that you don't have the
>> flexibility to re-order your allocations and deallocations - this is
>> strictly stack ordering.
>
> A bigger disadvantage is that it is unusable even in many cases where stack
> ordering would be fine.  If a loop needed to create a temporary variable-
> length object whose length is computed within the loop, that could easily
> be handled with alloca/freea; the only way to accomplish that without a
> freea() intrinsic is to move the inside of the loop into another function
> and prevent the compiler from inlining it.  Even with the added cost of a
> function call that approach would likely be cheaper than using malloc/free,
> but it would be rather brittle.  Further, if the compiler decides to inline
> the function stack use could easily skyrocket.
>

I can't follow what you mean here.  Can you give a rough example?

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

#102013

On Monday, January 16, 2017 at 5:22:06 PM UTC-6, David Brown wrote:
> On 16/01/17 17:35, supercat wrote:
> > A bigger disadvantage is that it is unusable even in many cases where stack
> > ordering would be fine.  If a loop needed to create a temporary variable-
> > length object whose length is computed within the loop, that could easily
> > be handled with alloca/freea; the only way to accomplish that without a
> > freea() intrinsic is to move the inside of the loop into another function
> > and prevent the compiler from inlining it.  Even with the added cost of a
> > function call that approach would likely be cheaper than using malloc/free,
> > but it would be rather brittle.  Further, if the compiler decides to inline
> > the function stack use could easily skyrocket.
> 
> I can't follow what you mean here.  Can you give a rough example?

Sure.  Consider the code:

    void process_file_records(FILE *f)
    {
      uint16_t record_size;
      while(fread(&record_size, 2, 1, f) && record_size)
      {
        void *dat = malloc(record_size);
        if (!dat) exit(-1);
        fread(dat, 1, record_size, f);
        process_record(dat, record_size);
        free(dat);
        more_stuff_not_needing_dat();
      }
    }

If "process_record" never keeps a copy of "dat", the storage identified by
the pointer won't have to outlive the function, and code will never destroy
anything other than the most recent live object created.  Such code would
thus be a good candidate for alloca if there were a balancing freea
available.  The only way for such code to take advantage of alloca,
however, would be to pull all the logic that handles each record into its
own function which would allocate stack storage shortly after entry, and
release that storage when it exits.

    void do_stuff_with_one_record(FILE *f, uint16_t record_size)
    {
      void *dat = alloca(record_size);
      if (!dat) exit(-1);
      fread(dat, 1, record_size, f);
      process_record(dat, record_size);
    }

    void process_file_records(FILE *f)
    {
      uint16_t record_size;
      while(fread(&record_size, 2, 1, f) && record_size)
      {
        do_stuff_with_one_record(f, record_size);
        more_stuff_not_needing_dat();
      }
    }

That would work, but it's not a great subdivision of functionality between
the two functions.  Worse, if a compiler decides to inline the call to
do_stuff_with_one_record, the storage reserved by the inner function's
call to alloca() may not get released until after the outer function
returns, meaning that all of the records from the input data stream would
need to fit on the stack *simultaneously*.  Oops.

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

#102017

On 17/01/17 01:23, supercat@casperkitty.com wrote:
> On Monday, January 16, 2017 at 5:22:06 PM UTC-6, David Brown wrote:
>> On 16/01/17 17:35, supercat wrote:
>>> A bigger disadvantage is that it is unusable even in many cases where stack
>>> ordering would be fine.  If a loop needed to create a temporary variable-
>>> length object whose length is computed within the loop, that could easily
>>> be handled with alloca/freea; the only way to accomplish that without a
>>> freea() intrinsic is to move the inside of the loop into another function
>>> and prevent the compiler from inlining it.  Even with the added cost of a
>>> function call that approach would likely be cheaper than using malloc/free,
>>> but it would be rather brittle.  Further, if the compiler decides to inline
>>> the function stack use could easily skyrocket.
>>
>> I can't follow what you mean here.  Can you give a rough example?
>
> Sure.  Consider the code:
>
>     void process_file_records(FILE *f)
>     {
>       uint16_t record_size;
>       while(fread(&record_size, 2, 1, f) && record_size)
>       {
>         void *dat = malloc(record_size);
>         if (!dat) exit(-1);
>         fread(dat, 1, record_size, f);
>         process_record(dat, record_size);
>         free(dat);
>         more_stuff_not_needing_dat();
>       }
>     }
>

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.

But just use VLA's.  They are deallocated at the end of their scope.

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

#102018

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

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

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

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

csiph-web