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

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

Array allocated on stack or heap

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

Contents

  Array allocated on stack or heap Prashant Shah <pshah.mumbai@gmail.com> - 2017-03-16 22:58 -0700
    Re: Array allocated on stack or heap Barry Schwarz <schwarzb@dqel.com> - 2017-03-16 23:57 -0700
      Re: Array allocated on stack or heap Mark Storkamp <mstorkamp@yahoo.com> - 2017-03-17 12:44 -0500
        Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-17 11:26 -0700
          Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-17 20:38 +0100
            Re: Array allocated on stack or heap Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-17 16:08 -0400
              Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-18 00:03 +0100
                Re: Array allocated on stack or heap Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-17 20:54 -0400
    Re: Array allocated on stack or heap John Bode <jfbode1029@gmail.com> - 2017-03-17 12:15 -0700
      Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-17 20:22 +0100
      Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-17 20:45 +0100
        Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-17 12:59 -0700
        Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-17 21:01 +0100
          Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-18 00:12 +0100
            Re: Array allocated on stack or heap jameskuyper@verizon.net - 2017-03-17 16:25 -0700
              Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-17 17:08 -0700
                Re: Array allocated on stack or heap Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-17 17:37 -0700
            Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-19 12:30 +0100
              Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 12:12 +0000
                Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-19 13:52 +0100
                  Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 16:51 +0000
                    Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-20 10:44 +0100
                      Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-20 12:01 +0000
                        Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-20 06:02 -0700
                          Re: Array allocated on stack or heap GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-20 14:54 +0100
                            Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-20 07:28 -0700
                              Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-20 16:43 +0100
                              Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-20 09:02 -0700
                                Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-21 10:11 +0100
                                  Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-21 02:48 -0700
                                    Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-21 08:19 -0700
                                  Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-21 08:17 -0700
                                    Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-21 09:06 -0700
                                    Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-21 17:32 +0100
                              Re: Array allocated on stack or heap Les Cargill <lcargill99@comcast.com> - 2017-03-25 15:14 -0500
                                Re: Array allocated on stack or heap Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-25 16:05 -0700
                                  Re: Array allocated on stack or heap Les Cargill <lcargill99@comcast.com> - 2017-03-25 23:53 -0500
                                    Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-26 12:30 +0100
                                      Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-26 14:09 -0700
                                        Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-26 22:17 +0100
                                      Re: Array allocated on stack or heap Robert Wessel <robertwessel2@yahoo.com> - 2017-03-26 21:52 -0500
                                        Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-27 13:06 +0100
                                          Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-27 10:10 -0700
                                          Re: Array allocated on stack or heap Robert Wessel <robertwessel2@yahoo.com> - 2017-03-27 15:56 -0500
                                            Re: Array allocated on stack or heap bartc <bc@freeuk.com> - 2017-03-27 22:48 +0100
                                              Re: Array allocated on stack or heap Robert Wessel <robertwessel2@yahoo.com> - 2017-03-27 19:58 -0500
                          Re: Array allocated on stack or heap GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-20 14:56 +0100
                        Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-20 15:34 +0100
                          Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-20 09:28 -0700
                            Re: Array allocated on stack or heap bart4858@gmail.com - 2017-03-20 13:05 -0700
                              Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-20 13:53 -0700
                                Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-20 14:26 -0700
                                Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-20 22:24 +0000
                                  Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-20 15:44 -0700
                                    Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-21 02:44 -0700
                                  Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-21 11:15 +0100
                                    Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-21 11:12 +0000
                                      Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-21 04:23 -0700
                                      Re: Array allocated on stack or heap scott@slp53.sl.home (Scott Lurndal) - 2017-03-21 13:13 +0000
                                        Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-21 13:38 +0000
                                          Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-21 15:33 +0100
                                            Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-21 07:38 -0700
                                          Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-21 07:35 -0700
                                            Re: Array allocated on stack or heap scott@slp53.sl.home (Scott Lurndal) - 2017-03-21 15:09 +0000
                Re: Array allocated on stack or heap Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-19 13:05 +0000
                  Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 13:27 +0000
                  Re: Array allocated on stack or heap GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-19 14:26 +0100
                    Re: Array allocated on stack or heap Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-19 13:34 +0000
                      Re: Array allocated on stack or heap GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-19 14:35 +0100
                  Re: Array allocated on stack or heap Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-19 13:36 +0000
                    Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 14:00 +0000
                      Re: Array allocated on stack or heap Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-19 19:00 +0000
                        Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 19:24 +0000
                          Re: Array allocated on stack or heap Ian Collins <ian-news@hotmail.com> - 2017-03-20 08:45 +1300
                            Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-19 14:32 -0700
                              Re: Array allocated on stack or heap Ian Collins <ian-news@hotmail.com> - 2017-03-20 16:16 +1300
                                Re: Array allocated on stack or heap Gareth Owen <gwowen@gmail.com> - 2017-03-20 18:58 +0000
                              Re: Array allocated on stack or heap raltbos@xs4all.nl (Richard Bos) - 2017-03-24 09:17 +0000
                          Re: Array allocated on stack or heap Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-19 20:50 +0000
                Re: Array allocated on stack or heap GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-19 14:10 +0100
                  Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 13:38 +0000
                    Re: Array allocated on stack or heap GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-19 14:49 +0100
                      Re: Array allocated on stack or heap luser droog <luser.droog@gmail.com> - 2017-03-20 07:59 -0700
                Re: Array allocated on stack or heap Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-19 10:57 -0400
                  Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 16:14 +0000
                    Re: Array allocated on stack or heap Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-19 15:53 -0400
                      Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 20:37 +0000
                        Re: Array allocated on stack or heap Jean-Marc Bourguet <jm@bourguet.org> - 2017-03-19 23:09 +0100
                          Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 22:38 +0000
                            Re: Array allocated on stack or heap Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-19 16:21 -0700
                            Re: Array allocated on stack or heap Ian Collins <ian-news@hotmail.com> - 2017-03-20 16:18 +1300
                          Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-20 11:06 +0100
                    Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-20 11:00 +0100
                Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-19 08:53 -0700
        Re: Array allocated on stack or heap Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-17 16:11 -0400
        Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-17 13:35 -0700
          Re: Array allocated on stack or heap Chad <cdalten@gmail.com> - 2017-03-17 14:00 -0700
            Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-17 23:57 +0100
              Re: Array allocated on stack or heap Ian Collins <ian-news@hotmail.com> - 2017-03-18 12:42 +1300
                Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-18 00:45 +0100
              Re: Array allocated on stack or heap Chad <cdalten@gmail.com> - 2017-03-18 14:17 -0700
                Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-19 19:21 +0100
                  Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-19 15:00 -0700
                    Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 22:16 +0000
                      Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-19 23:57 +0100
                        Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-19 16:15 -0700
                        Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-20 12:24 +0100
                      Re: Array allocated on stack or heap scott@slp53.sl.home (Scott Lurndal) - 2017-03-20 13:24 +0000
              Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-19 13:21 +0100
        Re: Array allocated on stack or heap John Bode <jfbode1029@gmail.com> - 2017-03-17 14:30 -0700
          Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-17 23:59 +0100
          Re: Array allocated on stack or heap Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-17 21:02 -0400
          Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-19 13:26 +0100

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

#106314 — Array allocated on stack or heap

Hi,

I just wanted to know whether array when declared as local function variable is  allocated on stack or heap.

#include <stdio.h>

void check_array() {
    int a[20000]; // stack or heap ??
    .....
}

int main(int argc, char *argv[]) {
    check_array();
    return 0;
}

[toc] | [next] | [standalone]

#106320

On Thu, 16 Mar 2017 22:58:54 -0700 (PDT), Prashant Shah
<pshah.mumbai@gmail.com> wrote:

>Hi,
>
>I just wanted to know whether array when declared as local function variable is  allocated on stack or heap.
>
>#include <stdio.h>
>
>void check_array() {
>    int a[20000]; // stack or heap ??
>    .....
>}
>
>int main(int argc, char *argv[]) {
>    check_array();
>    return 0;
>}

If you are willing to accept common usage of the terms, defined
objects are placed on the stack while allocated memory is obtained
from the heap.  

Be aware that neither stack nor heap appears in the standard.  Not all
machines have a stack.  It is the compiler writer's choice how memory
is reserved for defined objects.  It is the run-time library writer's
choice how the allocation routines interface with the operating system
(if there is one) to obtain memory.

This is all very system specific.

If you change your code slightly to

void check_array(int *p)
   {...}
int main(void)
   {int a[20000];
    int *b = malloc(20000*sizeof *b);
    check_array(a);
    check_array(b);
    return;}

There is no portable way for check_array to know whether p contains
the address of a defined array or an allocated one.

-- 
Remove del for email

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

#106365

In article <6f1ncc9c5jto8p8tdes73rfpts1ub37td5@4ax.com>,
 Barry Schwarz <schwarzb@dqel.com> wrote:

> On Thu, 16 Mar 2017 22:58:54 -0700 (PDT), Prashant Shah
> <pshah.mumbai@gmail.com> wrote:
> 
> >Hi,
> >
> >I just wanted to know whether array when declared as local function variable 
> >is  allocated on stack or heap.
> >
> >#include <stdio.h>
> >
> >void check_array() {
> >    int a[20000]; // stack or heap ??
> >    .....
> >}
> >
> >int main(int argc, char *argv[]) {
> >    check_array();
> >    return 0;
> >}
> 
> If you are willing to accept common usage of the terms, defined
> objects are placed on the stack while allocated memory is obtained
> from the heap.  
> 
> Be aware that neither stack nor heap appears in the standard.  Not all
> machines have a stack.  It is the compiler writer's choice how memory
> is reserved for defined objects.  It is the run-time library writer's
> choice how the allocation routines interface with the operating system
> (if there is one) to obtain memory.
> 
> This is all very system specific.
> 
> If you change your code slightly to
> 
> void check_array(int *p)
>    {...}
> int main(void)
>    {int a[20000];
>     int *b = malloc(20000*sizeof *b);
>     check_array(a);
>     check_array(b);
>     return;}
> 
> There is no portable way for check_array to know whether p contains
> the address of a defined array or an allocated one.

And to add to what Barry said, if you had

void check_array() {
  static int a[20000];
  .....
}

then by common usage of the terms stack and heap, a would be allocated 
in the heap. (All usual conditions, exceptions &c apply).

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

#106373

Mark Storkamp <mstorkamp@yahoo.com> writes:
[...]
> And to add to what Barry said, if you had
>
> void check_array() {
>   static int a[20000];
>   .....
> }
>
> then by common usage of the terms stack and heap, a would be allocated 
> in the heap. (All usual conditions, exceptions &c apply).

Incorrect.  In typical implementations, objects with static storage
(defined with the "static" keyword and/or at file scope) are allocated
in a separate region of memory that's set up when the program is loaded.
It continues to be allocated during the entire execution of the program.
This is distinct from both the "stack" and the "heap" (the latter is
allocated and deallocated by calls to malloc, free, and equivalents).

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

#106382

Le 17/03/2017 à 19:26, Keith Thompson a écrit :
> Mark Storkamp <mstorkamp@yahoo.com> writes:
> [...]
>> And to add to what Barry said, if you had
>>
>> void check_array() {
>>   static int a[20000];
>>   .....
>> }
>>
>> then by common usage of the terms stack and heap, a would be allocated
>> in the heap. (All usual conditions, exceptions &c apply).
>
> Incorrect.

Yes, that is a big error. Statics are allocated in the program's data 
space and initialized to zero at program start. They do not change their 
values from one usage to the next. This data space can hold static 
memory of arguments or states or whatever, that needs to be passed from 
one invocation to the next.


In typical implementations, objects with static storage
> (defined with the "static" keyword and/or at file scope) are allocated
> in a separate region of memory that's set up when the program is loaded.


Yes. In most implementations this is called "bss", and it is marked to 
be zeroed at program start by the program loader.

> It continues to be allocated during the entire execution of the program.
> This is distinct from both the "stack" and the "heap" (the latter is
> allocated and deallocated by calls to malloc, free, and equivalents).
>

Stack and heaps do not conserve the data from one invocation to the next 
since they are dynamic data, not static obviously. They move. The stack 
and heap increase or decrease during the execution of the program.

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

#106388

On 3/17/2017 3:38 PM, jacobnavia wrote:
> Le 17/03/2017 à 19:26, Keith Thompson a écrit :
>> Mark Storkamp <mstorkamp@yahoo.com> writes:
>> [...]
>>> And to add to what Barry said, if you had
>>>
>>> void check_array() {
>>>   static int a[20000];
>>>   .....
>>> }
>>>
>>> then by common usage of the terms stack and heap, a would be allocated
>>> in the heap. (All usual conditions, exceptions &c apply).
>>
>> Incorrect.
> 
> Yes, that is a big error. Statics are allocated in the program's data
> space and initialized to zero at program start. They do not change their
> values from one usage to the next. This data space can hold static
> memory of arguments or states or whatever, that needs to be passed from
> one invocation to the next.
>

Incorrect.  Every time the program starts up the storage is allocated
and initialized to zero.  When the program terminates, this memory is
released back to the OS.  There is nothing saved from one invocation to
the next.

> 
> In typical implementations, objects with static storage
>> (defined with the "static" keyword and/or at file scope) are allocated
>> in a separate region of memory that's set up when the program is loaded.
> 
> 
> Yes. In most implementations this is called "bss", and it is marked to
> be zeroed at program start by the program loader.
> 
>> It continues to be allocated during the entire execution of the program.
>> This is distinct from both the "stack" and the "heap" (the latter is
>> allocated and deallocated by calls to malloc, free, and equivalents).
>>
> 
> Stack and heaps do not conserve the data from one invocation to the next
> since they are dynamic data, not static obviously. They move. The stack
> and heap increase or decrease during the execution of the program.
> 
> 



-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#106399

Le 17/03/2017 à 21:08, Jerry Stuckle a écrit :
> Incorrect.  Every time the program starts up the storage is allocated
> and initialized to zero.  When the program terminates, this memory is
> released back to the OS.  There is nothing saved from one invocation to
> the next.

Invocation meant function calls, and many functions can be called 
different times within the execution history of the program. I was 
talking about THAT and not different invocations of the same program.

Of course you can play the pedantic guy and be obtuse. If that is what 
you want you won jerry.

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

#106424

On 3/17/2017 7:03 PM, jacobnavia wrote:
> Le 17/03/2017 à 21:08, Jerry Stuckle a écrit :
>> Incorrect.  Every time the program starts up the storage is allocated
>> and initialized to zero.  When the program terminates, this memory is
>> released back to the OS.  There is nothing saved from one invocation to
>> the next.
> 
> Invocation meant function calls, and many functions can be called
> different times within the execution history of the program. I was
> talking about THAT and not different invocations of the same program.
> 
> Of course you can play the pedantic guy and be obtuse. If that is what
> you want you won jerry.
> 
> 

Invocation generally means program start.  If you're talking about
something else, you need to be clear on the matter.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#106377

On Friday, March 17, 2017 at 12:59:12 AM UTC-5, Prashant Shah wrote:
> Hi,
> 
> I just wanted to know whether array when declared as local function variable is  allocated on stack or heap.
> 
> #include <stdio.h>
> 
> void check_array() {
>     int a[20000]; // stack or heap ??
>     .....
> }
> 
> int main(int argc, char *argv[]) {
>     check_array();
>     return 0;
> }

The real-world implementations I know of would try to place it on the
runtime stack, but that's strictly a function of the implementation, not
the language definition.  All the language definition specifies is *when*
and for how long memory is to be set aside for the object, not *where*.  

Having said that, the C language was developed on a system that used a
runtime stack, and the rules for "auto" objects *strongly* encourage the 
use of a stack.  

But, there's really nothing to stop an implementation from trying to 
allocate "auto" objects from the heap, other than the bookkeeping involved
and the possible performance implications.  I don't know of any that do,
but that doesn't mean they don't exist.  When in doubt, consult the 
documentation for your implementation.

But as a rule, the *only* objects that would be allocated from the heap
would be anything created with malloc(), calloc(), or realloc().

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

#106379

On 17/03/17 20:15, John Bode wrote:
> On Friday, March 17, 2017 at 12:59:12 AM UTC-5, Prashant Shah wrote:
>> Hi,
>>
>> I just wanted to know whether array when declared as local function variable is  allocated on stack or heap.
>>
>> #include <stdio.h>
>>
>> void check_array() {
>>     int a[20000]; // stack or heap ??
>>     .....
>> }
>>
>> int main(int argc, char *argv[]) {
>>     check_array();
>>     return 0;
>> }
>
> The real-world implementations I know of would try to place it on the
> runtime stack, but that's strictly a function of the implementation, not
> the language definition.  All the language definition specifies is *when*
> and for how long memory is to be set aside for the object, not *where*.
>
> Having said that, the C language was developed on a system that used a
> runtime stack, and the rules for "auto" objects *strongly* encourage the
> use of a stack.
>
> But, there's really nothing to stop an implementation from trying to
> allocate "auto" objects from the heap, other than the bookkeeping involved
> and the possible performance implications.  I don't know of any that do,
> but that doesn't mean they don't exist.  When in doubt, consult the
> documentation for your implementation.
>
> But as a rule, the *only* objects that would be allocated from the heap
> would be anything created with malloc(), calloc(), or realloc().
>

There are a few embedded C implementations that try to allocate as much 
as possible statically, rather than on the stack, because the target 
processor has poor support for accessing data on a stack.  If the 
compiler can be sure that check_array() is not used recursively, it 
would allocate a fixed static address for the array (possibly overlapped 
with local variables from other functions).  However, such devices 
rarely have anything like enough ram for a 20,000 int array - so it's 
unlikely that the OP is using that sort of C compiler!

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

#106383

Le 17/03/2017 à 20:15, John Bode a écrit :
> The real-world implementations I know of would try to place it on the
> runtime stack, but that's strictly a function of the implementation, not
> the language definition.  All the language definition specifies is *when*
> and for how long memory is to be set aside for the object, not *where*.

The language definition defines a logical stack of nested scopes.

You enter a scope and push the old contents of the workspace to make 
place for a new scope with new data. You do your calculations and exit 
the scope with (or without) result. You pop the old context and you 
continue.

You can enter a scope and exit it in a stack-like manner. Now, it is 
obvious since almost all CPUs have a machine stack, that the best thing 
to do is to implement the C stack using the machine's stack pointer.

Obviously.

I never thought somebody would discuss such obvious facts.

The C language does imply a stack, and most implementations use the 
machine stack since it is built for doing exactly that: a stack.

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

#106386

On Friday, March 17, 2017 at 2:45:19 PM UTC-5, jacobnavia wrote:
> You can enter a scope and exit it in a stack-like manner. Now, it is 
> obvious since almost all CPUs have a machine stack, that the best thing 
> to do is to implement the C stack using the machine's stack pointer.

On some processors base+displacement algorithm is very cheap; on others it is
very expensive.  On something like the C2xx DSP platform, it's possible for
a compiler to use the stack for local variables, but the performance of non-
recursive functions will be much better if the compiler is told that certain
functions will not be called re-entrantly and that it can use static storage
for their automatic variables instead of the stack.  The compiler can even
recognize when such functions do not directly or indirectly call any outside
code and share such "auto-static" storage between them.  Compilers for a
number of other formerly-popular embedded platforms like the Z80 and 68HC11
which could have benefited from similar options, though the closest thing
I've seen to them was user-declared macros which expanded to "static" when
using such platforms (but could be changed to expand to nothing when using
a platform with fast frame-relative addressing).

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

#106387

On 17/03/17 20:45, jacobnavia wrote:
> Le 17/03/2017 à 20:15, John Bode a écrit :
>> The real-world implementations I know of would try to place it on the
>> runtime stack, but that's strictly a function of the implementation, not
>> the language definition.  All the language definition specifies is *when*
>> and for how long memory is to be set aside for the object, not *where*.
>
> The language definition defines a logical stack of nested scopes.
>
> You enter a scope and push the old contents of the workspace to make
> place for a new scope with new data. You do your calculations and exit
> the scope with (or without) result. You pop the old context and you
> continue.
>
> You can enter a scope and exit it in a stack-like manner. Now, it is
> obvious since almost all CPUs have a machine stack, that the best thing
> to do is to implement the C stack using the machine's stack pointer.
>
> Obviously.
>
> I never thought somebody would discuss such obvious facts.
>
> The C language does imply a stack, and most implementations use the
> machine stack since it is built for doing exactly that: a stack.
>
>

The key word here is "most".  Yes, /most/ implementations use a machine 
stack.  But some, especially for small microcontrollers, do not - or at 
least, the avoid using a stack as much as possible.  I have also used 
implementations where there were two stacks - one was used for function 
return addresses and temporary storage of registers (push and pop 
instructions), the other was used for a stack frame for local variables.

The C standards covers a wider range of implementations than just 
"most", and also applies to unusual or limited architectures.

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

#106402

Le 17/03/2017 à 21:01, David Brown a écrit :
> On 17/03/17 20:45, jacobnavia wrote:
>>
>> You can enter a scope and exit it in a stack-like manner. Now, it is
>> obvious since almost all CPUs have a machine stack, that the best thing
>> to do is to implement the C stack using the machine's stack pointer.
>>
>
> The key word here is "most".  Yes, /most/ implementations use a machine
> stack.

Thanks, we agree on that then. Most implementations use a machine stack 
since C was invented.

But some, especially for small microcontrollers, do not - or at
> least, the avoid using a stack as much as possible.

Yes, there can be weird, small circuits that have special needs. In some 
machines you can implement the stack in a fixed portion since all 
procedures will always push the same amount of workspace into the stack 
at each time unless they use VLAs but I would pressumes that those are 
banned.

I have also used
> implementations where there were two stacks - one was used for function
> return addresses and temporary storage of registers (push and pop
> instructions), the other was used for a stack frame for local variables.
>

Great but for most machines that is moot, there is a single register 
used for the machine stack. All risc machines, all Intel processors, all 
IBM Cell processors, the motorola machines, the Z80 and I can go on with 
almost every micro-computer chip outside some weirdos and small 
controllers that have just a few registers and can use a few K of RAM.

> The C standards covers a wider range of implementations than just
> "most", and also applies to unusual or limited architectures.
>

True, nobody is discussing that. But when speaking about C it is 
important to explain this feature in a manner that is easy to undertsnad 
and corresponds to the majority of machines we are going to use.

And no, C is not only used in a few odd processors. It is one of the 
most used programming languages in the world and its scope goes WAY 
beyond a micro-controller somewhere. That is why it is important to stop 
spreading confusion and show always some weirdo machine that is 
different than any other. Yes portability is important, but let's keep 
the proportions right. If you say in a footnote "Some machines have no 
machine stack and their C implementations implement the stacked 
procedure entry/return stack in different manners" ok. But to tell 
newcomers that outside a footnote maybe is just CONFUSING THE ISSUE for 
them.

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

#106405

On Friday, March 17, 2017 at 7:13:06 PM UTC-4, jacobnavia wrote:
...
> True, nobody is discussing that. But when speaking about C it is 
> important to explain this feature in a manner that is easy to undertsnad 
> and corresponds to the majority of machines we are going to use.

True, but it's also important to avoid explaining the feature in a manner that can lead to the misunderstanding that all machines work the same way as the most common machines. It's easy for people to acquire the delusion that all systems behave the same way as the ones they're most familiar with. To fight that delusion it's essential that the existence of other ways of doing things be frequently acknowledged, and when relevant, explained.

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

#106416

jameskuyper@verizon.net writes:
> On Friday, March 17, 2017 at 7:13:06 PM UTC-4, jacobnavia wrote:
> ...
>> True, nobody is discussing that. But when speaking about C it is 
>> important to explain this feature in a manner that is easy to undertsnad 
>> and corresponds to the majority of machines we are going to use.
>
> True, but it's also important to avoid explaining the feature in a
> manner that can lead to the misunderstanding that all machines work
> the same way as the most common machines. It's easy for people to
> acquire the delusion that all systems behave the same way as the ones
> they're most familiar with. To fight that delusion it's essential that
> the existence of other ways of doing things be frequently
> acknowledged, and when relevant, explained.

And someone who thinks that all C implementations use a contiguous
hardware stack might be tempted to write code that relies on that
assumption, for example comparing addresses to determine how far up
or down the stack they are.  That kind of knowledge can be handy for
debugging, but it's a bad idea to depend on it even if it happens to
be true for the current implementation (among other things, it's UB).

All you really need to know to write good C code is that automatic
allocation occurs in a last-in first-out manner.

Admittedly some programmers might prefer a more concrete mental model,
but IMHO it's a good idea to keep in mind which details of that model
are actually guaranteed by the language and which aren't.

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

#106420

On Saturday, March 18, 2017 at 12:08:43 AM UTC, Keith Thompson wrote:
> jameskuyper@verizon.net writes:
> > On Friday, March 17, 2017 at 7:13:06 PM UTC-4, jacobnavia wrote:
> > ...
> >> True, nobody is discussing that. But when speaking about C it is 
> >> important to explain this feature in a manner that is easy to undertsnad 
> >> and corresponds to the majority of machines we are going to use.
> >
> > True, but it's also important to avoid explaining the feature in a
> > manner that can lead to the misunderstanding that all machines work
> > the same way as the most common machines. It's easy for people to
> > acquire the delusion that all systems behave the same way as the ones
> > they're most familiar with. To fight that delusion it's essential that
> > the existence of other ways of doing things be frequently
> > acknowledged, and when relevant, explained.
> 
> And someone who thinks that all C implementations use a contiguous
> hardware stack might be tempted to write code that relies on that
> assumption, for example comparing addresses to determine how far up
> or down the stack they are.  That kind of knowledge can be handy for
> debugging, but it's a bad idea to depend on it even if it happens to
> be true for the current implementation (among other things, it's UB).
> 
> All you really need to know to write good C code is that automatic
> allocation occurs in a last-in first-out manner.
> 
> Admittedly some programmers might prefer a more concrete mental model,
> but IMHO it's a good idea to keep in mind which details of that model
> are actually guaranteed by the language and which aren't.
> 
Actually some small embedded compilers put variables in known places 
in memory.So effectively everything is static, with the exception
that you can have overlays, so two variables might share the same
address. Needless to say, if you run out of addresses, you need
to understand the model to rewrite the code so that more overlays are
possible.

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

#106472

On 18/03/17 00:12, jacobnavia wrote:
> Le 17/03/2017 à 21:01, David Brown a écrit :
>> On 17/03/17 20:45, jacobnavia wrote:
>>>
>>> You can enter a scope and exit it in a stack-like manner. Now, it is
>>> obvious since almost all CPUs have a machine stack, that the best thing
>>> to do is to implement the C stack using the machine's stack pointer.
>>>
>>
>> The key word here is "most".  Yes, /most/ implementations use a machine
>> stack.
>
> Thanks, we agree on that then. Most implementations use a machine stack
> since C was invented.
>
> But some, especially for small microcontrollers, do not - or at
>> least, the avoid using a stack as much as possible.
>
> Yes, there can be weird, small circuits that have special needs. In some
> machines you can implement the stack in a fixed portion since all
> procedures will always push the same amount of workspace into the stack
> at each time unless they use VLAs but I would pressumes that those are
> banned.
>

These "weird, small circuits" are the dominant type of processor.  There 
are vastly more small, limited microcontrollers around than x86 or PPC 
processors.

I am happy to agree that most C programmers will deal only with systems 
that have a single simple stack (per thread).  I just like to make it 
clear that this is not the only way C is implemented - there are very 
common, real-world C implementations that have no stack or make minimal 
use of a stack.  This is not just a hypothetical case, or very rare or 
unusual devices.

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

#106475

On 19/03/2017 11:30, David Brown wrote:
> On 18/03/17 00:12, jacobnavia wrote:

> These "weird, small circuits" are the dominant type of processor.  There
> are vastly more small, limited microcontrollers around than x86 or PPC
> processors.
>
> I am happy to agree that most C programmers will deal only with systems
> that have a single simple stack (per thread).  I just like to make it
> clear that this is not the only way C is implemented - there are very
> common, real-world C implementations that have no stack or make minimal
> use of a stack.  This is not just a hypothetical case, or very rare or
> unusual devices.


This has been discussed a few times but is it right that a language like 
C should be permanently crippled, so that it can continue to work on 
these tiny or oddball processors that can barely be termed computers. Or 
should it be split?

That is, allow a streamlined version that is designed to work on what 
most people think of as a computer.

Take the basic types for example:

In Java, the types {byte, short, int, long} have widths {8, 16, 32, 64}.

In C#, the types {sbyte, short, int, long} have widths {8, 16, 32, 64}.

In Rust, they seem to be {i8, i16, i32, i64} (you can guess the widths).

In Go, they are {int8, int16, int32, int64}.

There's a common pattern. Now look at the types in C:

   {char, short, int, long, long long}

For a start, there are five instead of four! Now for the widths (not 
checked, but you get the picture):

  { at least 8, but no longer than the width of short,
    at least 16 but not longer than int,
    at least 16 but not longer than long,
    at least 32 but not longer than long long
    at least 64}

Plus the fact that all types are signed, except for char which may be 
signed OR unsigned, a fact you might not even know.

Anyone notice an obvious way that this mess could be tidied up?

And yes I know about the attempt to superimpose a more modern set of 
four types onto those five using: {int8_t, int16_t, int32_t, int64_t} 
with widths, if you are lucky, of {8, 16, 32, 64}.

But that doesn't really cut it. For one thing, programs still use 'int' 
everywhere, whose width is not fixed. They still use 'char' of unknown 
signedness. Programs also tend to use 'size_t', whose size might be 32 
or 64, or maybe something else, and which is /probably/ unsigned (I'd 
need to check that).

Then there are still issues with the widths of float, double and long 
double. Plus the hoops to jump through to be able to print an intN_t type.

If the ties to the old C that has to work on everything are cut, then a 
lot of things not just types could be tidied up.

-- 
bartc

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

#106482

On 19/03/17 13:12, BartC wrote:
> On 19/03/2017 11:30, David Brown wrote:
>> On 18/03/17 00:12, jacobnavia wrote:
>
>> These "weird, small circuits" are the dominant type of processor.  There
>> are vastly more small, limited microcontrollers around than x86 or PPC
>> processors.
>>
>> I am happy to agree that most C programmers will deal only with systems
>> that have a single simple stack (per thread).  I just like to make it
>> clear that this is not the only way C is implemented - there are very
>> common, real-world C implementations that have no stack or make minimal
>> use of a stack.  This is not just a hypothetical case, or very rare or
>> unusual devices.
>
>
> This has been discussed a few times but is it right that a language like
> C should be permanently crippled, so that it can continue to work on
> these tiny or oddball processors that can barely be termed computers. Or
> should it be split?
>

There would be a reasonable argument for a split, /if/ the language were 
being "crippled" by support for more limited (or outdated) systems.  But 
I don't believe that is the case.  In this example, what benefit would 
there be to people writing portable C code that they expect to run 
mainly on PC's, if they knew that all there target systems had a 
hardware stack?

(Note that there is already a split - between "hosted C environments" 
and "free-standing C environments".  You can read about the difference 
in the standards.)


> That is, allow a streamlined version that is designed to work on what
> most people think of as a computer.
>
> Take the basic types for example:
>
> In Java, the types {byte, short, int, long} have widths {8, 16, 32, 64}.
>
> In C#, the types {sbyte, short, int, long} have widths {8, 16, 32, 64}.
>
> In Rust, they seem to be {i8, i16, i32, i64} (you can guess the widths).
>
> In Go, they are {int8, int16, int32, int64}.
>
> There's a common pattern. Now look at the types in C:
>
>   {char, short, int, long, long long}
>
> For a start, there are five instead of four! Now for the widths (not
> checked, but you get the picture):
>
>  { at least 8, but no longer than the width of short,
>    at least 16 but not longer than int,
>    at least 16 but not longer than long,
>    at least 32 but not longer than long long
>    at least 64}
>
> Plus the fact that all types are signed, except for char which may be
> signed OR unsigned, a fact you might not even know.

If you care whether "char" is signed or unsigned, you have been careless 
in your coding.

>
> Anyone notice an obvious way that this mess could be tidied up?

Yes - you could introduce some size-specific types so that people who 
needed tighter specifications for their integer types could say exactly 
what they wanted.  In order to make this system practical on a range of 
systems, you would want the most specific types to be optional for 
platforms where they could not work practically - you'd make this 
"implementation dependent best effort".  That way, common systems would 
have full support, and others would support what they could.

That would be a new way to get standard sized integer types.  You could 
conveniently collect them into a header, called something like 
<stdint.h> for brevity.  If only someone had thought of that when C99 
was written!

>
> And yes I know about the attempt to superimpose a more modern set of
> four types onto those five using: {int8_t, int16_t, int32_t, int64_t}
> with widths, if you are lucky, of {8, 16, 32, 64}.
>
> But that doesn't really cut it. For one thing, programs still use 'int'
> everywhere,

"An integer type of range at least -32767 .. 32767 that works 
efficiently" is a good enough specification for a great many common 
variables.  And many programs have other limitations (such as the use of 
Windows or *nix library calls) that imply "int" must be at least 32-bit 
- again, that makes it a perfectly good choice.

> whose width is not fixed. They still use 'char' of unknown
> signedness.

Most uses of "char" are for storing letters or characters, or for 
abstract byte storage - the signedness does not matter.

> Programs also tend to use 'size_t', whose size might be 32
> or 64, or maybe something else, and which is /probably/ unsigned (I'd
> need to check that).

And the exact size of size_t either does not matter, or what matters is 
that the size is appropriate for the platform in question.  Sometimes 
platform-specific size is more useful than fixed size.

>
> Then there are still issues with the widths of float, double and long
> double. Plus the hoops to jump through to be able to print an intN_t type.
>
> If the ties to the old C that has to work on everything are cut, then a
> lot of things not just types could be tidied up.
>

A few things could be "tidied up" - but not many.  I used to think as 
you do here, until looking at it in more detail - there is surprisingly 
little that could be specified more tightly that would actually be 
significantly helpful in coding.  And the potentially big gains would 
come from making more drastic assumptions - such as fixing CHAR_BIT at 8 
at the cost of excluding a good many DSP devices.

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

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

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

csiph-web