Automatic arrays vs malloc
David Scarlett
array if the size is known at compile time? As I understand it, the
automatic array would be stored on the stack, while the malloc'd space
is not. So would it be easy to fill up your stack if you define large,
automatic arrays? (And consequently, is it better to malloc them
instead?)
Thanks.
--
David Scarlett
Remove "eminemsucks" to reply via email.
Joona I Palaste
> Is there much difference between mallocing space and using an automatic
> array if the size is known at compile time? As I understand it, the
> automatic array would be stored on the stack, while the malloc'd space
> is not. So would it be easy to fill up your stack if you define large,
> automatic arrays? (And consequently, is it better to malloc them
> instead?)
ISO standard C has no concept of "stack". Even though most
implementations work like you said, no one is forcing them to.
Another advantage of malloc() over automatic arrays is that automatic
arrays take up memory space for the whole duration of your function,
while malloc()'ed memory only takes up memory space from the malloc()
call to the free() call.
Using malloc() also lets you nicely handle situations when you have too
little memory. If there's not enough memory to allocate an automatic
array, your program will quite probably just quit there and then. In
some situations it might not even start in the first place. Using
malloc() will return NULL at that point, leaving you to handle the
situation yourself.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Remember: There are only three kinds of people - those who can count and those
who can't."
- Vampyra
Peter Nilsson
news:Xns929FB65D6...@210.49.20.254...
> Is there much difference between mallocing space and using an automatic
> array if the size is known at compile time? As I understand it, the
> automatic array would be stored on the stack, while the malloc'd space
> is not. So would it be easy to fill up your stack if you define large,
> automatic arrays? (And consequently, is it better to malloc them
> instead?)
"Large" fixed sized arrays are best made static. If such an array must be
instantiated within deeply nested recursive function calls, then malloc is
the way to go. Having said that, some implementations will let malloc return
non-NULL even when there is not enough memory left...
As you can see, these are pragmatic issues; not something easily justified
under the C standard(s).
--
Peter
Malcolm
"Peter Nilsson" <ai...@acay.com.au> wrote in message
>
> "Large" fixed sized arrays are best made static. If such an array must be
> instantiated within deeply nested recursive function calls, then malloc is
> the way to go. Having said that, some implementations will let malloc
return
> non-NULL even when there is not enough memory left...
>
of the program, whilst it is likely that the array is only required for some
part of the program, and memory can usefully be recycled. malloc() is then
preferable.
An implementation that returns an invalid pointer from malloc() is broken.
Simon Biber
> > Having said that, some implementations will let malloc
> > return non-NULL even when there is not enough memory
> > left...
"Malcolm" <mal...@55bank.freeserve.co.uk> replied:
> An implementation that returns an invalid pointer from
> malloc() is broken.
Some common implementations (eg. GLibC on Linux, IIRC) will always return a
"valid" pointer, but when you attempt to use it, if there's not enough
memory, the program will get an out-of-memory signal. In my opinion, it's
not strictly conforming behaviour.
--
Simon.
Richard Heathfield
>
> "Peter Nilsson" <ai...@acay.com.au> wrote in message
> >
> > "Large" fixed sized arrays are best made static. If such an array must be
> > instantiated within deeply nested recursive function calls, then malloc is
> > the way to go. Having said that, some implementations will let malloc
> return
> > non-NULL even when there is not enough memory left...
> >
> The problem with a static array is that the memory is used for the duration
> of the program, whilst it is likely that the array is only required for some
> part of the program, and memory can usefully be recycled. malloc() is then
> preferable.
That depends on the implementor's interpretation of the C Standard. It
is possible to read it either as requiring that freed memory continue to
be available for use by the program (in which case it makes no
difference either way in this case), or as not requiring that (in which
case you are, or at least might be, correct).
> An implementation that returns an invalid pointer from malloc() is broken.
Indeed.
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Kevin Easton
It is, because the OS can stop the program at any time it likes. The
standard can't force an implementation to run all programs to completion
- otherwise it'd be quite hard to write a strictly conforming
implementation on a computer that didn't have a UPS, for example.
- Kevin.
Richard Heathfield
AFAICT there is no "strictly conforming" category for implementations.
They are either conforming or non-conforming. "Strictly conforming" is
an attribute of programs.
The Standard says, in section 4 (Conformance):
5 A strictly conforming program shall use only those features of the
language and library
specified in this International Standard.2) It shall not produce output
dependent on any
unspecified, undefined, or implementation-defined behavior, and shall
not exceed any
minimum implementation limit.
6 The two forms of conforming implementation are hosted and
freestanding. A conforming
hosted implementation shall accept any strictly conforming program. A
conforming
freestanding implementation shall accept any strictly conforming program
that does not
use complex types and in which the use of the features specified in the
library clause
(clause 7) is confined to the contents of the standard headers
<float.h>,
<iso646.h>, <limits.h>, <stdarg.h>, <stdbool.h>, <stddef.h>, and
<stdint.h>. A conforming implementation may have extensions (including
additional
library functions), provided they do not alter the behavior of any
strictly conforming
program.3)
Sam Reynolds
We talked about this here:
To quote Stig Brautaset
"However, you indicate that you're using Linux, so go then and read the
malloc() manpage. The last paragraph says this:
Linux follows an optimistic memory allocation strategy. This
means that when malloc() returns non-NULL there is no
guarantee that the memory really is available. In case it turns
out that the system is out of memory, one or more processes
will be killed by the infamous OOM killer."
The standard seems to disallow this, I have seen it myself many many
times. I wonder if there is some loophole somewhere they are
exploiting, or if it is not conforming.
--
Sam Reynolds
cl...@chool.com
Ben Pfaff
> To quote Stig Brautaset
>
> "However, you indicate that you're using Linux, so go then and read the
> malloc() manpage. The last paragraph says this:
>
> Linux follows an optimistic memory allocation strategy. This
> means that when malloc() returns non-NULL there is no
> guarantee that the memory really is available. In case it turns
> out that the system is out of memory, one or more processes
> will be killed by the infamous OOM killer."
(OT: If this really bothers you, turn off Linux overcommit using
the files in /proc/sys/vm.)
--
"I hope, some day, to learn to read.
It seems to be even harder than writing."
--Richard Heathfield
Sam Reynolds
> Sam Reynolds <cl...@chool.com> writes:
>
>
>>To quote Stig Brautaset
>>
>>"However, you indicate that you're using Linux, so go then and read the
>>malloc() manpage. The last paragraph says this:
>>
>> Linux follows an optimistic memory allocation strategy. This
>> means that when malloc() returns non-NULL there is no
>> guarantee that the memory really is available. In case it turns
>> out that the system is out of memory, one or more processes
>> will be killed by the infamous OOM killer."
>
>
> (OT: If this really bothers you, turn off Linux overcommit using
> the files in /proc/sys/vm.)
Doesn't bother me at all, just pointing out that the return
from malloc may not be as rock-solid in the real world
as the standard suggests it should be.
--
Sam Reynolds
cl...@chool.com