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

#101847 — Dinamic array without malloc - Can be done?

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)

May be I have a conceptual error here, but just in case I did prefer to ask.

I want to do something like this:

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


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.


Thanks.-

[toc] | [next] | [standalone]

#101848

On 15/01/2017 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)
>
> May be I have a conceptual error here, but just in case I did prefer to ask.
>
> I want to do something like this:
>
> len = (some calculated length that can vary in every execution);
> char myArray[len];
>
>
> 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.

It should work; did you put the code inside a function? Eg:

  int main(void) {
    int len=rand()+100;
    char myArray[len];

    printf("%d\n",(int)sizeof(myArray));

  }

The array is allocated on the stack and is deallocated at a matching "}".

(This is a C 'VLA'.)

-- 
Bartc

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

#101852

W dniu niedziela, 15 stycznia 2017 17:53:57 UTC+1 użytkownik Bart napisał:
> On 15/01/2017 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)
> >
> > May be I have a conceptual error here, but just in case I did prefer to ask.
> >
> > I want to do something like this:
> >
> > len = (some calculated length that can vary in every execution);
> > char myArray[len];
> >
> >
> > 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.
> 
> It should work; did you put the code inside a function? Eg:
> 
>   int main(void) {
>     int len=rand()+100;
>     char myArray[len];
> 
>     printf("%d\n",(int)sizeof(myArray));
> 
>   }
> 
> The array is allocated on the stack and is deallocated at a matching "}".
> 
> (This is a C 'VLA'.)
> 

i should rethink the limits of this method.. do you know them maybe? (many arrays could be used in function body?
each one freely resized? etc)

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

#102077

On 15/01/2017 17:34, fir wrote:
> W dniu niedziela, 15 stycznia 2017 17:53:57 UTC+1 użytkownik Bart napisał:
>> On 15/01/2017 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)
>>>
>>> May be I have a conceptual error here, but just in case I did prefer to ask.
>>>
>>> I want to do something like this:
>>>
>>> len = (some calculated length that can vary in every execution);
>>> char myArray[len];
>>>
>>>
>>> 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.
>>
>> It should work; did you put the code inside a function? Eg:
>>
>>   int main(void) {
>>     int len=rand()+100;
>>     char myArray[len];
>>
>>     printf("%d\n",(int)sizeof(myArray));
>>
>>   }
>>
>> The array is allocated on the stack and is deallocated at a matching "}".
>>
>> (This is a C 'VLA'.)
>>
>
> i should rethink the limits of this method.. do you know them maybe? (many arrays could be used in function body?
> each one freely resized? etc)

Any number of such arrays can be declared.

The space is deallocated at the end of the block in which the array is 
declared. Or by leaving the block via goto or return.

They can't be resized except by 're-executing' the declaration:

int n;

n=10;
{
L:;
   char a[n];

   printf("SIZE=%d\n",sizeof(a));
   n=n*2;
   if (n<100) goto  L;
}

This prints 10, 20, 40 and 80.

I've no idea how it manages it, since it is presumably deallocating and 
then reallocating even within the same block. The compiler does however 
stop you jumping /into/ such a block (by-passing the declaration for 
example).

So in all it's a nasty little feature IMO full of gotchas if you're 
unfortunate enough to have the job of implementing it.

(And which I would never use, except by accident, as my need is for 
flexible arrays that which grow in size.)

-- 
bartc

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

#102082

W dniu wtorek, 17 stycznia 2017 22:10:05 UTC+1 użytkownik Bart napisał:
> On 15/01/2017 17:34, fir wrote:
> > W dniu niedziela, 15 stycznia 2017 17:53:57 UTC+1 użytkownik Bart napisał:
> >> On 15/01/2017 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)
> >>>
> >>> May be I have a conceptual error here, but just in case I did prefer to ask.
> >>>
> >>> I want to do something like this:
> >>>
> >>> len = (some calculated length that can vary in every execution);
> >>> char myArray[len];
> >>>
> >>>
> >>> 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.
> >>
> >> It should work; did you put the code inside a function? Eg:
> >>
> >>   int main(void) {
> >>     int len=rand()+100;
> >>     char myArray[len];
> >>
> >>     printf("%d\n",(int)sizeof(myArray));
> >>
> >>   }
> >>
> >> The array is allocated on the stack and is deallocated at a matching "}".
> >>
> >> (This is a C 'VLA'.)
> >>
> >
> > i should rethink the limits of this method.. do you know them maybe? (many arrays could be used in function body?
> > each one freely resized? etc)
> 
> Any number of such arrays can be declared.
> 
> The space is deallocated at the end of the block in which the array is 
> declared. Or by leaving the block via goto or return.
> 
> They can't be resized except by 're-executing' the declaration:
> 
> int n;
> 
> n=10;
> {
> L:;
>    char a[n];
> 
>    printf("SIZE=%d\n",sizeof(a));
>    n=n*2;
>    if (n<100) goto  L;
> }
> 
> This prints 10, 20, 40 and 80.
> 
> I've no idea how it manages it, since it is presumably deallocating and 
> then reallocating even within the same block. The compiler does however 
> stop you jumping /into/ such a block (by-passing the declaration for 
> example).
> 
> So in all it's a nasty little feature IMO full of gotchas if you're 
> unfortunate enough to have the job of implementing it.
> 
> (And which I would never use, except by accident, as my need is for 
> flexible arrays that which grow in size.)
> 

this not leaves the block so i thought it shouldnt 
resize... but i dont know.. some said on this that 1] it
not accumulates allocations (unlike alloca).. 2] thought it is also not resizable (like alloca made).. 3] and it deallocks after block exit (unlike alloca)

i dont think it should be hard to implement.. what could be hard? you will only need to remember stack pointer
locations and revert to it after leaving the block, something like that.. 

more problem is if this has sense.. it may have some 
sense.. though for example as local variables in blocks
are not 'deleted' after block exit (afair) but are unaccesible (afair) maybe here it should work this way
(im not sure).... btw if it is ok with those variables im also not sure (in both cases if they should be deleted
and if should be necessarely unaccesible )

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

#102084

W dniu wtorek, 17 stycznia 2017 22:45:16 UTC+1 użytkownik fir napisał:
> W dniu wtorek, 17 stycznia 2017 22:10:05 UTC+1 użytkownik Bart napisał:
> > On 15/01/2017 17:34, fir wrote:
> > > W dniu niedziela, 15 stycznia 2017 17:53:57 UTC+1 użytkownik Bart napisał:
> > >> On 15/01/2017 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)
> > >>>
> > >>> May be I have a conceptual error here, but just in case I did prefer to ask.
> > >>>
> > >>> I want to do something like this:
> > >>>
> > >>> len = (some calculated length that can vary in every execution);
> > >>> char myArray[len];
> > >>>
> > >>>
> > >>> 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.
> > >>
> > >> It should work; did you put the code inside a function? Eg:
> > >>
> > >>   int main(void) {
> > >>     int len=rand()+100;
> > >>     char myArray[len];
> > >>
> > >>     printf("%d\n",(int)sizeof(myArray));
> > >>
> > >>   }
> > >>
> > >> The array is allocated on the stack and is deallocated at a matching "}".
> > >>
> > >> (This is a C 'VLA'.)
> > >>
> > >
> > > i should rethink the limits of this method.. do you know them maybe? (many arrays could be used in function body?
> > > each one freely resized? etc)
> > 
> > Any number of such arrays can be declared.
> > 
> > The space is deallocated at the end of the block in which the array is 
> > declared. Or by leaving the block via goto or return.
> > 
> > They can't be resized except by 're-executing' the declaration:
> > 
> > int n;
> > 
> > n=10;
> > {
> > L:;
> >    char a[n];
> > 
> >    printf("SIZE=%d\n",sizeof(a));
> >    n=n*2;
> >    if (n<100) goto  L;
> > }
> > 
> > This prints 10, 20, 40 and 80.
> > 
> > I've no idea how it manages it, since it is presumably deallocating and 
> > then reallocating even within the same block. The compiler does however 
> > stop you jumping /into/ such a block (by-passing the declaration for 
> > example).
> > 
> > So in all it's a nasty little feature IMO full of gotchas if you're 
> > unfortunate enough to have the job of implementing it.
> > 
> > (And which I would never use, except by accident, as my need is for 
> > flexible arrays that which grow in size.)
> > 
> 
> this not leaves the block so i thought it shouldnt 
> resize... but i dont know.. some said on this that 1] it
> not accumulates allocations (unlike alloca).. 2] thought it is also not resizable (like alloca made).. 3] and it deallocks after block exit (unlike alloca)
> 
> i dont think it should be hard to implement.. what could be hard? you will only need to remember stack pointer
> locations and revert to it after leaving the block, something like that.. 
> 
> more problem is if this has sense.. it may have some 
> sense.. though for example as local variables in blocks
> are not 'deleted' after block exit (afair) but are unaccesible (afair) maybe here it should work this way
> (im not sure).... btw if it is ok with those variables im also not sure (in both cases if they should be deleted
> and if should be necessarely unaccesible )

making this vla bein deletable at block exit probably
makes that other can be used in more cases

foo()
{
 for(;;)
 {
  {
  int aaa[rand()%10];
  }

  {
  int bbb[rand()%10];
  }

  {
  int ccc[rand()%10];
  }
 }
}

that could probably work becouse if all other are destroyed the new still can be recreated

where 

foo()
{
 for(;;)
 {
  int aaa[rand()%10];
  int bbb[rand()%10];
  int ccc[rand()%10];
 }
}

in such case it seem aaa bbb ccc may be allocked but
aaa cannot be resized

so it seems that this block destroy could be usefull
but im not sure if it is enough to justify this way..
maybe..

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

#102086

On 17/01/2017 21:45, fir wrote:
> W dniu wtorek, 17 stycznia 2017 22:10:05 UTC+1 użytkownik Bart napisał:

>> They can't be resized except by 're-executing' the declaration:
>>
>> int n;
>>
>> n=10;
>> {
>> L:;
>>    char a[n];
>>
>>    printf("SIZE=%d\n",sizeof(a));
>>    n=n*2;
>>    if (n<100) goto  L;
>> }
>>
>> This prints 10, 20, 40 and 80.
>>
>> I've no idea how it manages it, since it is presumably deallocating and
>> then reallocating even within the same block.

> this not leaves the block so i thought it shouldnt
> resize... but i dont know.. some said on this that 1] it
> not accumulates allocations (unlike alloca).. 2] thought it is also not resizable (like alloca made).. 3] and it deallocks after block exit (unlike alloca)
>
> i dont think it should be hard to implement.. what could be hard? you will only need to remember stack pointer
> locations and revert to it after leaving the block, something like that..

OK, try and rewrite the example using:

* char** a instead of char a[]

* stackalloc() and stackfree() to allocate from the stack (or /a/
   stack)and deallocate (these /must/ be correctly paired)

* Sizeof(a) which returns the bytes allocated in a, as sizeof does for
   the VLA (you don't need to implement these functions, just show calls
   to them)

* stackfree must be called on any exit from the block: /if/ any VLA is
   active and local to that block

* a must be reallocated if the declaration line is reentered.

Now imagine that you don't have just this one simple example, but 
possibly dozens of such VLAs of varying scopes with gotos, returns and 
block ends everywhere.

-- 
Bartc

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

#102087

On Tuesday, January 17, 2017 at 3:45:16 PM UTC-6, fir wrote:
> i dont think it should be hard to implement.. what could be hard? you will only need to remember stack pointer
> locations and revert to it after leaving the block, something like that..

A VLA is destroyed any time control leaves the block *or* goes to an area
of the block preceding its declaration.  One significant semantic change
in C99 which occurred as a consequence of easing the rule about the
placement of variable declarations is that it is not possible to have a
"goto" target label between the start of a block and a declaration, which
makes it necessary to add more rules about the effect of branching to one.

Somewhat curiously, if declaration does not have a VLA type nor an
initializer, the variable will retain its value if a "goto" transfers
execution to a point above the declaration but in the same block and a
second "goto" transfers control back below the declaration, but the
value would become Indeterminate if execution actually reaches the
declaration.  The rule is different for VLA types, since the lifetime
of those would end when execution is transferred above them.

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

#102092

W dniu środa, 18 stycznia 2017 00:06:28 UTC+1 użytkownik supe...@casperkitty.com napisał:
> On Tuesday, January 17, 2017 at 3:45:16 PM UTC-6, fir wrote:
> > i dont think it should be hard to implement.. what could be hard? you will only need to remember stack pointer
> > locations and revert to it after leaving the block, something like that..
> 
> A VLA is destroyed any time control leaves the block *or* goes to an area
> of the block preceding its declaration.  One significant semantic change
> in C99 which occurred as a consequence of easing the rule about the
> placement of variable declarations is that it is not possible to have a
> "goto" target label between the start of a block and a declaration, which
> makes it necessary to add more rules about the effect of branching to one.
> 
> Somewhat curiously, if declaration does not have a VLA type nor an
> initializer, the variable will retain its value if a "goto" transfers
> execution to a point above the declaration but in the same block and a
> second "goto" transfers control back below the declaration, but the
> value would become Indeterminate if execution actually reaches the
> declaration.  The rule is different for VLA types, since the lifetime
> of those would end when execution is transferred above them.

you should maybe considering writing 2 or 3 shorter sentences instead one 350 characters long,
(you write sentences in that scheme often:

assume blablablablablablabla then blablablablablablablabla 
umles blablablablablablabla when blablablablablablabla or 
blablablablablablabla then blablablablablabla

i mean you do not close the sentence and one must 
train memory remembering 300 chars and 5 bends/turns
when you go to sentence conclusion - its a bit like monty python imo (esp it is not necessary and i just get bored
remembering this)
 (or ir not shorter just close the parts
in separation not making reader waiting a 60 seconds to
reach the end far far away to allow to begin remembering
what you wrote )

(im allso accused of writing weird sentences but i 
dont think i write this way (my own closed parts of sentence are shorter i belive )

i dont think thet if you will jump before vla declaration
and then jump back below it the vla value will change (if you want say so)

i mean like here

int n=10;

aa:
if(n==20) goto bb;

 int vla[n];

 n = 20;
 goto aa;
bb:

 it would be to weird, imo vla value should change
only if controll will go thru it
 

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

#102093

supercat@casperkitty.com writes:
[...]
> A VLA is destroyed any time control leaves the block *or* goes to an area
> of the block preceding its declaration.  One significant semantic change
> in C99 which occurred as a consequence of easing the rule about the
> placement of variable declarations is that it is not possible to have a
> "goto" target label between the start of a block and a declaration, which
> makes it necessary to add more rules about the effect of branching to one.

The change in C99 is that it *is* possible to have such a label.

For VLAs:

    A goto statement shall not jump from outside the scope of an
    identifier having a variably modified type to inside the scope of
    that identifier.

[...]

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

#102098

On Tuesday, January 17, 2017 at 6:56:22 PM UTC-6, Keith Thompson wrote:
> supercat writes:
> [...]
> > A VLA is destroyed any time control leaves the block *or* goes to an area
> > of the block preceding its declaration.  One significant semantic change
> > in C99 which occurred as a consequence of easing the rule about the
> > placement of variable declarations is that it is not possible to have a
> > "goto" target label between the start of a block and a declaration, which
> > makes it necessary to add more rules about the effect of branching to one.
> 
> The change in C99 is that it *is* possible to have such a label.
> 
> For VLAs:
> 
>     A goto statement shall not jump from outside the scope of an
>     identifier having a variably modified type to inside the scope of
>     that identifier.

The Standard also notes that for non-VLA variables, the lifetime ends when
control leaves the *block* containing the variable, but for VLAs it ends
when control leaves the *scope*.  This effectively implies that if a VLA
declaration is preceded by a label and followed by a goto targeting that
label, non-VLA declarations within that block may need to be hoisted.

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

#102102

On 18/01/17 05:37, supercat@casperkitty.com wrote:
> On Tuesday, January 17, 2017 at 6:56:22 PM UTC-6, Keith Thompson wrote:
>> supercat writes:
>> [...]
>>> A VLA is destroyed any time control leaves the block *or* goes to an area
>>> of the block preceding its declaration.  One significant semantic change
>>> in C99 which occurred as a consequence of easing the rule about the
>>> placement of variable declarations is that it is not possible to have a
>>> "goto" target label between the start of a block and a declaration, which
>>> makes it necessary to add more rules about the effect of branching to one.
>>
>> The change in C99 is that it *is* possible to have such a label.
>>
>> For VLAs:
>>
>>     A goto statement shall not jump from outside the scope of an
>>     identifier having a variably modified type to inside the scope of
>>     that identifier.
> 
> The Standard also notes that for non-VLA variables, the lifetime ends when
> control leaves the *block* containing the variable, but for VLAs it ends
> when control leaves the *scope*.  This effectively implies that if a VLA
> declaration is preceded by a label and followed by a goto targeting that
> label, non-VLA declarations within that block may need to be hoisted.
> 

That sounds reasonable.  The compiler can easily hoist fixed-size
declarations to the start of a block (or any enclosing block).  But it
can't hoist a VLA declaration to anywhere earlier than the expression
giving its size.

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

#102847

supercat@casperkitty.com writes:

> On Tuesday, January 17, 2017 at 6:56:22 PM UTC-6, Keith Thompson wrote:
>> supercat writes:
>> [...]
>>> A VLA is destroyed any time control leaves the block *or* goes to an area
>>> of the block preceding its declaration.  One significant semantic change
>>> in C99 which occurred as a consequence of easing the rule about the
>>> placement of variable declarations is that it is not possible to have a
>>> "goto" target label between the start of a block and a declaration, which
>>> makes it necessary to add more rules about the effect of branching to one.
>>
>> The change in C99 is that it *is* possible to have such a label.
>>
>> For VLAs:
>>
>>     A goto statement shall not jump from outside the scope of an
>>     identifier having a variably modified type to inside the scope of
>>     that identifier.
>
> The Standard also notes that for non-VLA variables, the lifetime ends when
> control leaves the *block* containing the variable, but for VLAs it ends
> when control leaves the *scope*.  This effectively implies that if a VLA
> declaration is preceded by a label and followed by a goto targeting that
> label, non-VLA declarations within that block may need to be hoisted.

Not so.  It may be that there would be some benefit to
hoisting other declarations, but never a need to do so.

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

#102854

On Tuesday, January 31, 2017 at 10:49:23 AM UTC-6, Tim Rentsch wrote:
> supercat writes:
> > The Standard also notes that for non-VLA variables, the lifetime ends when
> > control leaves the *block* containing the variable, but for VLAs it ends
> > when control leaves the *scope*.  This effectively implies that if a VLA
> > declaration is preceded by a label and followed by a goto targeting that
> > label, non-VLA declarations within that block may need to be hoisted.
> 
> Not so.  It may be that there would be some benefit to
> hoisting other declarations, but never a need to do so.

I failed to allow for the possibility that an implementation could store
VLAs using some means other than LIFO allocation on the same stack used
for other automatic variables, but that would add substantial complexity
which would defeat much of the purpose of having VLAs as a language
feature.  If an implementation allocates VLAs on the LIFO stack as other
variables, I see no way to avoid a requirement to hoist the variable "x"
in the following:

    void test(void)
    {
      int sz=10;
      FOO:
        int arr[sz];
        if (sz==10)
          outside_function1(arr);
        else
          outside_function3(arr);

        int x;
        if (sz==10)
        {
          sz=outside_function2(&x);
          goto FOO;
        }
    }

This code makes three outside function calls.  When outside_function2() is
called, the array passed to the first call is required to still exist at
the same address, and the passed-in address must identify an "int" which
is disjoint from that.  When outside_function3() is called, it is required
to receive an array of the size indicated by outside_function2 [which may
be larger than ten], and since execution has never left the scope of x,
that variable must also still exist at the same address it had when
outside_function2 was called.

Is there any means of accomplishing those requirements while allocating
things from a single LIFO stack, other than by hoisting x?

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

#102855

On Tuesday, January 31, 2017 at 12:39:39 PM UTC-6, supe...@casperkitty.com wrote:

>       FOO:
>         int arr[sz];

Labels must be on statements and a declaration
is not a statement.

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

#102859

On Tuesday, January 31, 2017 at 12:56:02 PM UTC-6, luser droog wrote:
> On Tuesday, January 31, 2017 at 12:39:39 PM UTC-6, supe...@casperkitty.com wrote:
> 
> >       FOO:
> >         int arr[sz];
> 
> Labels must be on statements and a declaration
> is not a statement.

Sorry.  Throw some do-nothing statement after "foo".  What's important is
that C99, unlike C89, allows code to jump from a point after a declaration
to a point before the declaration without ending the lifetime of the
object thus declared.

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

#102857

On Tuesday, January 31, 2017 at 1:39:39 PM UTC-5, supe...@casperkitty.com wrote:
> Is there any means of accomplishing those requirements while allocating
> things from a single LIFO stack, other than by hoisting x?

I ran into the same issue with CAlive's local allocation algorithms.  I
wound up deciding on creating two schemes.  One directly allocates a
block and must be met by the LIFO protocol.  The other is a dynamic
 allocation which allocates blocks as needed, freeing individual blocks
as needed, but it really doesn't free space until the lowest block is
freed.  Still useful as it auto-frees upon return, but a little more
messy.

    CAlive to introduce lnew, ldelete, lalloc(), lfree(), lstackin() and lstackout()
    https://groups.google.com/d/msg/caliveprogramminglanguage/bFZ3icj-bQg/MTrrjkO0BgAJ

Thank you,
Rick C. Hodgin

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

#103122

supercat@casperkitty.com writes:

> On Tuesday, January 31, 2017 at 10:49:23 AM UTC-6, Tim Rentsch wrote:
>> supercat writes:
>>> The Standard also notes that for non-VLA variables, the lifetime ends when
>>> control leaves the *block* containing the variable, but for VLAs it ends
>>> when control leaves the *scope*.  This effectively implies that if a VLA
>>> declaration is preceded by a label and followed by a goto targeting that
>>> label, non-VLA declarations within that block may need to be hoisted.
>>
>> Not so.  It may be that there would be some benefit to
>> hoisting other declarations, but never a need to do so.
>
> I failed to allow for the possibility that [allocations
> might be made outside the local stack frame].  [...]
>
> [long example, and question framed in the context of the example]

It may be that we are using terminology in different ways.  Can
you phrase the question without using the word "hoist" (or
"hoisted", etc)?  You may assume that memory allocation is
confined to the local stack frame (with a floating boundary at
one end, obviously).

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

#101860

El domingo, 15 de enero de 2017, 17:53:57 (UTC+1), Bart  escribió:
<snip> 
>
> It should work; did you put the code inside a function? Eg:
> 
>   int main(void) {
>     int len=rand()+100;
>     char myArray[len];
> 
>     printf("%d\n",(int)sizeof(myArray));
> 
>   }
> 
> The array is allocated on the stack and is deallocated at a matching "}".
> 
> (This is a C 'VLA'.)
> 
> -- 
> Bartc


Ok, I've re-tested again (last time was 3-4 days ago and I can't remember how exactly I did) and it works:


    int len = strlen(argv[1]);
    char myArray[len];
    printf("myArray: len=%i\n", len);
    myArray[0] = 'A';
    myArray[1] = '\0';
    int len2 = strlen(myArray);
    printf("myArray: len2=%i\n", len2);
    myArray[0] = 'A';
    myArray[1] = 'B';
    myArray[2] = 'C';
    myArray[3] = '\0';
    len2 = strlen(myArray);
    printf("myArray: len2=%i\n", len2);


Even I can define an initial length and do whatever I need inside it, like changing the '\0' termination of the string, between the initial limits.

Thanks Bart!

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

#101876

On 15/01/2017 18:42, Fernando D. Bozzo wrote:
> El domingo, 15 de enero de 2017, 17:53:57 (UTC+1), Bart  escribió:
> <snip>
>>
>> It should work; did you put the code inside a function? Eg:
>>
>>   int main(void) {
>>     int len=rand()+100;
>>     char myArray[len];
>>
>>     printf("%d\n",(int)sizeof(myArray));

> Ok, I've re-tested again (last time was 3-4 days ago and I can't remember how exactly I did) and it works:
>
>
>     int len = strlen(argv[1]);
>     char myArray[len];
>     printf("myArray: len=%i\n", len);

Displaying sizeof(myArray) is more useful confirmation. Otherwise this 
line will give a result even if the char myArray line didn't exist.

>     myArray[0] = 'A';
>     myArray[1] = '\0';

This assumes that len is at least two. And below, that it is a least 4. 
But len can be 0 or 1.

>     int len2 = strlen(myArray);
>     printf("myArray: len2=%i\n", len2);
>     myArray[0] = 'A';
>     myArray[1] = 'B';
>     myArray[2] = 'C';
>     myArray[3] = '\0';

-- 
Bartc

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

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

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

csiph-web