Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #58631 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2015-03-22 01:51 -0700 |
| Last post | 2015-03-24 10:39 +0100 |
| Articles | 14 on this page of 74 — 16 participants |
Back to article view | Back to comp.lang.c
local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-22 01:51 -0700
local arrays and stack asetofsymbols@gmail.com - 2015-03-22 02:23 -0700
Re: local arrays and stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-22 13:22 -0700
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 01:55 -0700
Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-22 15:07 -0700
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 01:50 -0700
Re: local arrays and stack Robert Wessel <robertwessel2@yahoo.com> - 2015-03-23 04:26 -0500
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 06:53 -0700
Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-23 07:29 -0700
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 08:34 -0700
Re: local arrays and stack Robert Wessel <robertwessel2@yahoo.com> - 2015-03-23 19:57 -0500
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-24 04:01 -0700
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-24 04:37 -0700
Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-24 13:04 +0100
Re: local arrays and stack glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-03-24 17:29 +0000
Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-24 20:01 +0100
Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-23 08:24 -0700
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 08:42 -0700
Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-23 16:07 +0000
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 09:15 -0700
Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-23 09:16 -0700
Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-23 16:34 +0000
Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-23 10:12 -0700
Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-23 17:44 +0000
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 11:47 -0700
Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-23 12:06 -0700
Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-23 20:25 +0000
Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-23 14:10 -0700
Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-23 22:22 +0000
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 23:57 -0700
Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-24 10:28 +0100
Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-24 10:44 +0000
Re: local arrays and stack Martin Shobe <martin.shobe@yahoo.com> - 2015-03-24 06:38 -0500
Re: local arrays and stack Martin Shobe <martin.shobe@yahoo.com> - 2015-03-24 09:57 -0500
Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-24 13:22 +0100
Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-25 16:07 +0000
Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-25 17:42 +0100
Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-25 19:06 +0000
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-25 12:26 -0700
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-25 13:20 -0700
Re: local arrays and stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-25 12:28 -0700
Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-25 21:45 +0100
Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-25 12:50 -0700
Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-25 22:33 +0000
Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-25 23:57 +0100
Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-25 21:42 +0100
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-25 09:55 -0700
Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-25 12:36 -0700
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-25 13:04 -0700
Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-25 21:52 +0100
Re: local arrays and stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-25 15:18 -0700
Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-26 00:02 +0100
Re: local arrays and stack Melzzzzz <mel@zzzzz.com> - 2015-03-26 00:47 +0100
Re: local arrays and stack Mel <mel@zzzzz.com> - 2015-03-24 14:58 +0100
Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-24 06:58 -0700
Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-23 14:34 -0700
Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-24 10:16 +0100
Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-24 09:55 +0100
Re: local arrays and stack Noob <root@127.0.0.1> - 2015-03-24 10:23 +0100
Re: local arrays and stack Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 12:18 -0700
Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-24 13:42 -0700
Re: local arrays and stack Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 08:47 -0700
Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-23 09:32 -0700
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 09:57 -0700
Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-23 10:37 -0700
Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-23 10:49 -0700
Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-23 12:48 -0700
Re: local arrays and stack jt@toerring.de (Jens Thoms Toerring) - 2015-03-23 22:29 +0000
Re: local arrays and stack James Kuyper <jameskuyper@verizon.net> - 2015-03-23 19:03 -0400
Re: local arrays and stack jt@toerring.de (Jens Thoms Toerring) - 2015-03-23 23:36 +0000
Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-24 02:17 -0700
Re: local arrays and stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-23 11:56 -0700
Re: local arrays and stack Robert Wessel <robertwessel2@yahoo.com> - 2015-03-23 20:00 -0500
Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-24 10:39 +0100
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-03-24 13:42 -0700 |
| Message-ID | <87384urut8.fsf@kst-u.example.com> |
| In reply to | #58865 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Bartc <bc@freeuk.com> writes:
>>> [snip]
>>
>> Does gcc *ever* (generate code to) allocate local non-static
>> arrays on the heap or in static memory? It would have to generate
>> code to explicitly deallocate the array, even in the presence of a
>> goto or longjmp() out of the scope. [snip]
>
> Certainly it would be nice if a compiler did manage to deallocate
> such arrays even in the presence of longjmp(), but strictly
> speaking I'm not sure there is a requirement to do so. So I
> think that's a QoI issue, not a conformance problem. Note that
> for VLA's there is an (informative) explicit remark in the
> Standard about this, in 7.13.2.1 p5. I don't see any text in the
> Standard that makes arrays that are not VLA's different in this
> regard (or for that matter, non-arrays either - if we had a big
> struct we might very well want to allocate it using non-stack
> memory).
The cited remark is:
EXAMPLE The longjmp function that returns control back to the point
of the setjmp invocation might cause memory associated with a
variable length array object to be squandered.
But paragraph 2 specifically addresses VLAs:
... or if the invocation of the setjmp macro was within the scope of
an identifier with variably modified type and execution has left
that scope in the interim, the behavior is undefined.
(If you're going to cite the standard, it would be useful to
copy-and-paste the actual text, or at least summarize it, for those who
don't have a copy handy.)
--
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]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-03-25 08:47 -0700 |
| Message-ID | <kfn7fu5cc4q.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #58877 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: >> Keith Thompson <kst-u@mib.org> writes: >>> Bartc <bc@freeuk.com> writes: >>>> [snip] >>> >>> Does gcc *ever* (generate code to) allocate local non-static >>> arrays on the heap or in static memory? It would have to generate >>> code to explicitly deallocate the array, even in the presence of a >>> goto or longjmp() out of the scope. [snip] >> >> Certainly it would be nice if a compiler did manage to deallocate >> such arrays even in the presence of longjmp(), but strictly >> speaking I'm not sure there is a requirement to do so. So I >> think that's a QoI issue, not a conformance problem. Note that >> for VLA's there is an (informative) explicit remark in the >> Standard about this, in 7.13.2.1 p5. I don't see any text in the >> Standard that makes arrays that are not VLA's different in this >> regard (or for that matter, non-arrays either - if we had a big >> struct we might very well want to allocate it using non-stack >> memory). > > The cited remark is: > > EXAMPLE The longjmp function that returns control back to the > point of the setjmp invocation might cause memory associated > with a variable length array object to be squandered. > > But paragraph 2 specifically addresses VLAs: > > ... or if the invocation of the setjmp macro was within the > scope of an identifier with variably modified type and > execution has left that scope in the interim, the behavior is > undefined. > > (If you're going to cite the standard, it would be useful to > copy-and-paste the actual text, or at least summarize it, for > those who don't have a copy handy.) That's true. Unfortunately I got tired of putting in the effort and catering to people who are simply too lazy to get a copy and look it up themselves.
[toc] | [prev] | [next] | [standalone]
| From | Xcott Craver <xcottcraver@gmail.com> |
|---|---|
| Date | 2015-03-23 09:32 -0700 |
| Message-ID | <c80c4036-d4a7-4a3d-9821-393b3ec9544c@googlegroups.com> |
| In reply to | #58757 |
On Monday, March 23, 2015 at 11:42:49 AM UTC-4, fir wrote: > > i thought that large ones are 'silently' moved to static area (stack is small, probably 2MB limit usually so how it could contain larger arrays? it could be silent move out of stack or compile error) (i may be mistaken here)) Hi, I can declare a 160MB array and see it on the stack. It's just a matter of subtracting the relevant offset from the stack pointer. I don't know if you have any artificial limits on your stack, but the only real impediment to its size is its address, and the amount of unused space below that address in memory. For a 32-bit or 64-bit address space, you should have plenty of room for very large arrays. --S
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-03-23 09:57 -0700 |
| Message-ID | <d414afab-2a86-42d7-a3a1-2492860a172d@googlegroups.com> |
| In reply to | #58761 |
W dniu poniedziałek, 23 marca 2015 17:32:28 UTC+1 użytkownik Xcott Craver napisał: > On Monday, March 23, 2015 at 11:42:49 AM UTC-4, fir wrote: > > > > i thought that large ones are 'silently' moved to static area (stack is small, probably 2MB limit usually so how it could contain larger arrays? it could be silent move out of stack or compile error) (i may be mistaken here)) > > Hi, > > I can declare a 160MB array and see it on the stack. It's just a matter > of subtracting the relevant offset from the stack pointer. > > I don't know if you have any artificial limits on your stack, but the only > real impediment to its size is its address, and the amount of unused space > below that address in memory. For a 32-bit or 64-bit address space, you > should have plenty of room for very large arrays. > > --S in what system? here on xp as i wroyte in other thread stack seem to be based 0023_0000 and grows down (till 0003_0000 probably)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-03-23 10:37 -0700 |
| Message-ID | <87bnjjty2r.fsf@kst-u.example.com> |
| In reply to | #58761 |
Xcott Craver <xcottcraver@gmail.com> writes:
> On Monday, March 23, 2015 at 11:42:49 AM UTC-4, fir wrote:
>> i thought that large ones are 'silently' moved to static area
>> (stack is small, probably 2MB limit usually so how it could contain
>> larger arrays? it could be silent move out of stack or compile
>> error) (i may be mistaken here))
>
> I can declare a 160MB array and see it on the stack. It's just a matter
> of subtracting the relevant offset from the stack pointer.
Using what implementation?
> I don't know if you have any artificial limits on your stack, but the only
> real impediment to its size is its address, and the amount of unused space
> below that address in memory. For a 32-bit or 64-bit address space, you
> should have plenty of room for very large arrays.
Some systems, including most or all Unix-like systems, do impose
limits on stack size. For example, on my system (Linux Mint 17),
the "ulimit" command indicates that the stack is limited to 8192
kbytes, though I can increase that limit. A small program that
defines a local array of 16 megabytes and assigns a value to its
last element dies with a segmentation fault. The seg fault goes
away if I increase the stack size limit (`ulimit -s unlimited`).
Because of this, it's typical to allocate large arrays statically
or via malloc(), not locally with automatic storage duration.
(And perhaps because most programmers do this, gcc has not, as far
as I know, implemented special-case handling for large local arrays.)
--
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]
| From | Xcott Craver <xcottcraver@gmail.com> |
|---|---|
| Date | 2015-03-23 10:49 -0700 |
| Message-ID | <56cd397c-bac6-4eac-ab5a-5548a9473140@googlegroups.com> |
| In reply to | #58772 |
On Monday, March 23, 2015 at 1:37:23 PM UTC-4, Keith Thompson wrote:
> Xcott Craver <@> writes:
> > I can declare a 160MB array and see it on the stack. It's just a matter
> > of subtracting the relevant offset from the stack pointer.
>
> Using what implementation?
64-bit OSX:
#define LEN 40000000
int main( void ) {
int array [LEN]; ....
(lldb) disas --name main
a.out`main at tester.c:12:
a.out[0x100000ec0]: pushq %rbp
a.out[0x100000ec1]: movq %rsp, %rbp
a.out[0x100000ec4]: subq $0x9896820, %rsp <---- 160000032 bytes
The ulimit command tells me that I apparently have an 8192K soft limit, and a
65532K hard limit on the stack. However, I can declare gigabyte-sized arrays,
and dissassembly just shows the function subtracting insane amounts from the
stack pointer.
--S
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-03-23 12:48 -0700 |
| Message-ID | <877fu7trzy.fsf@kst-u.example.com> |
| In reply to | #58774 |
Xcott Craver <xcottcraver@gmail.com> writes:
> On Monday, March 23, 2015 at 1:37:23 PM UTC-4, Keith Thompson wrote:
>> Xcott Craver <@> writes:
>> > I can declare a 160MB array and see it on the stack. It's just a matter
>> > of subtracting the relevant offset from the stack pointer.
>>
>> Using what implementation?
>
> 64-bit OSX:
>
> #define LEN 40000000
> int main( void ) {
> int array [LEN]; ....
>
> (lldb) disas --name main
> a.out`main at tester.c:12:
> a.out[0x100000ec0]: pushq %rbp
> a.out[0x100000ec1]: movq %rsp, %rbp
> a.out[0x100000ec4]: subq $0x9896820, %rsp <---- 160000032 bytes
>
> The ulimit command tells me that I apparently have an 8192K soft limit, and a
> 65532K hard limit on the stack. However, I can declare gigabyte-sized arrays,
> and dissassembly just shows the function subtracting insane amounts from the
> stack pointer.
I tried something similar on my system (Linux Mint, x86_64). When I
just declared the array, the program compiled and ran without error.
When I assigned a value to an element near the end of the array, it died
with a segmentation fault.
--
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]
| From | jt@toerring.de (Jens Thoms Toerring) |
|---|---|
| Date | 2015-03-23 22:29 +0000 |
| Message-ID | <cnbiemFpbilU1@mid.uni-berlin.de> |
| In reply to | #58782 |
Keith Thompson <kst-u@mib.org> wrote:
> Xcott Craver <xcottcraver@gmail.com> writes:
> > On Monday, March 23, 2015 at 1:37:23 PM UTC-4, Keith Thompson wrote:
> >> Xcott Craver <@> writes:
> >> > I can declare a 160MB array and see it on the stack. It's just a matter
> >> > of subtracting the relevant offset from the stack pointer.
> >>
> >> Using what implementation?
> >
> > 64-bit OSX:
> >
> > #define LEN 40000000
> > int main( void ) {
> > int array [LEN]; ....
> >
> > (lldb) disas --name main
> > a.out`main at tester.c:12:
> > a.out[0x100000ec0]: pushq %rbp
> > a.out[0x100000ec1]: movq %rsp, %rbp
> > a.out[0x100000ec4]: subq $0x9896820, %rsp <---- 160000032 bytes
> >
> > The ulimit command tells me that I apparently have an 8192K soft limit, and a
> > 65532K hard limit on the stack. However, I can declare gigabyte-sized arrays,
> > and dissassembly just shows the function subtracting insane amounts from the
> > stack pointer.
> I tried something similar on my system (Linux Mint, x86_64). When I
> just declared the array, the program compiled and ran without error.
> When I assigned a value to an element near the end of the array, it died
> with a segmentation fault.
For what I know that is the usual behaviour - the stack limit is
a system limit and results in the corresponding number of pages
automatically allocated for the stack at program start, but which
isn't checked for when the stack pointer is modified (would pro-
bably use quite a lot of CPU time to do that for each and every
stack pointer modification). So the stack pointer can quite easily
be modified by requesting too large a local array to point to un-
accessible memory and dereferencing it then results in a segmen-
tation fault (or worse, to memory that should be inaccessible but
isn't because the address is by chance or malicious intention some=
thing that points to mapped memory).
An interesting question is what exactly happens if you modify the
stack limit setting from within your program. Does it apply also
to he running program? Or only programs spawned from it? Never
thought about that yet;-)
Best regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-03-23 19:03 -0400 |
| Message-ID | <55109BB3.1080705@verizon.net> |
| In reply to | #58796 |
On 03/23/2015 06:29 PM, Jens Thoms Toerring wrote: ... > An interesting question is what exactly happens if you modify the > stack limit setting from within your program. Does it apply also > to he running program? Or only programs spawned from it? Never > thought about that yet;-) That's outside the scope of C. If I understand correctly, the POSIX setrlimit() function affects the current process and all subsequently spawned child processes - but I've seldom used it, and never for anything particularly complicated, so I could be mistaken.
[toc] | [prev] | [next] | [standalone]
| From | jt@toerring.de (Jens Thoms Toerring) |
|---|---|
| Date | 2015-03-23 23:36 +0000 |
| Message-ID | <cnbmbrFr1cbU1@mid.uni-berlin.de> |
| In reply to | #58802 |
James Kuyper <jameskuyper@verizon.net> wrote:
> On 03/23/2015 06:29 PM, Jens Thoms Toerring wrote:
> ...
> > An interesting question is what exactly happens if you modify the
> > stack limit setting from within your program. Does it apply also
> > to he running program? Or only programs spawned from it? Never
> > thought about that yet;-)
> That's outside the scope of C.
Yep, sorry. Should at least have added an <OT> marker. And that
paragraph was just the result of lazily considering things that
could possibly be done and then xgo wrong;-)
> If I understand correctly, the POSIX
> setrlimit() function affects the current process and all subsequently
> spawned child processes - but I've seldom used it, and never for
> anything particularly complicated, so I could be mistaken.
Before discussing that any further (and then in comp.unix.programming,
of course;-) I'd rather take a good look at the available documentation
resources as I've also rarely had to use setrlimit() for anything non-
trivial...
Best regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-03-24 02:17 -0700 |
| Message-ID | <a102b18e-c35e-4399-8823-657f967706dd@googlegroups.com> |
| In reply to | #58802 |
W dniu wtorek, 24 marca 2015 00:03:23 UTC+1 użytkownik James Kuyper napisał: > On 03/23/2015 06:29 PM, Jens Thoms Toerring wrote: > ... > > An interesting question is what exactly happens if you modify the > > stack limit setting from within your program. Does it apply also > > to he running program? Or only programs spawned from it? Never > > thought about that yet;-) > > That's outside the scope of C. If I understand correctly, the POSIX I disagree For me personaly various 'physical' implementations (of some c constructs, linking, runtime etc) are more interesting that standard quotations.. Thus i would be closer to say that standard talks are more off-topic that implementation talks (ofc i think both standard and implementations are 100% on topic here) > setrlimit() function affects the current process and all subsequently > spawned child processes - but I've seldom used it, and never for > anything particularly complicated, so I could be mistaken.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-03-23 11:56 -0700 |
| Message-ID | <c4a5b2e4-29f5-4d06-b931-3080b9183199@googlegroups.com> |
| In reply to | #58772 |
On Monday, March 23, 2015 at 5:37:23 PM UTC, Keith Thompson wrote: > > Some systems, including most or all Unix-like systems, do impose > limits on stack size. For example, on my system (Linux Mint 17), > the "ulimit" command indicates that the stack is limited to 8192 > kbytes, though I can increase that limit. A small program that > defines a local array of 16 megabytes and assigns a value to its > last element dies with a segmentation fault. The seg fault goes > away if I increase the stack size limit (`ulimit -s unlimited`). > > Because of this, it's typical to allocate large arrays statically > or via malloc(), not locally with automatic storage duration. > (And perhaps because most programmers do this, gcc has not, as far > as I know, implemented special-case handling for large local arrays. > Unless you use recursion, stack usage for a well-structured program is logarithmic with program size and complexity. 8 MB should be plenty. I initially misread it as 8KB, which is a bit mean, but should still be adequate unless you really want large buffers on the stack.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-03-23 20:00 -0500 |
| Message-ID | <ujd1hapbrr4fshc2ep1pigm3eep65vpp6s@4ax.com> |
| In reply to | #58754 |
On Mon, 23 Mar 2015 08:24:03 -0700, Keith Thompson <kst-u@mib.org> wrote: >Robert Wessel <robertwessel2@yahoo.com> writes: >> On Mon, 23 Mar 2015 01:50:41 -0700 (PDT), fir <profesor.fir@gmail.com> >> wrote: >[...] >>>anyway my quick test seem to showed that in mingw local arrays are not >>>placed on stack (maybe im mistaken) >> >> Certainly not small ones, or in general. > >Hmm? > >MinGW uses gcc as its compiler. As far as I know, all local non-static >objects (i.e., objects with automatic storage duration), including >arrays of any size, are allocated on the stack. It was more waffling more because I had never checked. It appears that neither GCC or MSVC have a limit to how big an object they'll allocate on the stack (even if it's nonsensically large). OTOH, I have seen the behavior on compilers for embedded systems.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-03-24 10:39 +0100 |
| Message-ID | <merbbh$gv1$1@dont-email.me> |
| In reply to | #58812 |
On 24/03/15 02:00, Robert Wessel wrote: > On Mon, 23 Mar 2015 08:24:03 -0700, Keith Thompson <kst-u@mib.org> > wrote: > >> Robert Wessel <robertwessel2@yahoo.com> writes: >>> On Mon, 23 Mar 2015 01:50:41 -0700 (PDT), fir <profesor.fir@gmail.com> >>> wrote: >> [...] >>>> anyway my quick test seem to showed that in mingw local arrays are not >>>> placed on stack (maybe im mistaken) >>> >>> Certainly not small ones, or in general. >> >> Hmm? >> >> MinGW uses gcc as its compiler. As far as I know, all local non-static >> objects (i.e., objects with automatic storage duration), including >> arrays of any size, are allocated on the stack. > > > It was more waffling more because I had never checked. It appears > that neither GCC or MSVC have a limit to how big an object they'll > allocate on the stack (even if it's nonsensically large). OTOH, I have > seen the behavior on compilers for embedded systems. > I have only seen such behaviour on embedded compilers for brain-dead processors like the 8051, where everything is allocated statically if possible, since access to data on the stack is so painful on such cpus. I certainly would not expect an embedded compiler to put any local data, of any size, in anything other than the same place (typically the stack) as all other local data.
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.c
csiph-web