By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,649 Members | 1,808 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,649 IT Pros & Developers. It's quick & easy.

When to use automatic variables and when to use malloc

P: n/a
I was reading the code of FFmpeg and it seems that they use malloc
just too much. The problems and dangers of malloc are widely known.
Malloc also has some overhead (although I don't know what is the
overhead of automatic variable sized arrays, I suspect it is smaller
than that of malloc), although I'm not too worried about it.

I was thinking that, with C99's variable length arrays, malloc
shouldn't be needed most of the time. But I'm not sure if it is
appropriate to declare everything as automatic variables, specially
for huge variables.

1-) When is it appropriate to use automatic variables?*

2-) If the problem is size, then what is the threshold?**

*I already know that we should be aware of the duration of the
variable, such as not to use an automatic variable as a buffer inside
a function, and then return the buffer. By the time the function
returns, the buffer is gone.

** Of course, I know this varies. But, given a reasonable system (say,
my Athlon XP 2600+ with 512 MB of RAM) and a reasonable OS (such as
GNU/Linux, and let's also include MS Windows because it is common),
can you give me an order of magnitude?

PS: I have googled first, and searched within this newsgroup before,
and I only found one previous discussion. It missed the point. People
kept arguing that automatic variables are fixed size, which is not
true anymore. People also kept arguing that malloc tells you when
there is not enough memory (by returning NULL) and allows you to do
something. I don't care much about it, since in the vast majority of
cases I just close the program when malloc fails. I have even written
a wrapper, so I don't have to check the pointer:

inline void *smalloc(size_t size){
void * const ptr=malloc(size);
if (ptr==NULL){
fputs("Function ",stderr);
fputs(__func__,stderr);
fputs(" called malloc and malloc returned NULL.\n",stderr);
perror(NULL);
exit(ENOMEM); // exit ou abort?
} else {
return ptr;
}
}

By the way, in the above case should I have used abort() or is exit()
ok? From the respective manual pages, I can't tell.

Feb 20 '07 #1
Share this Question
Share on Google+
58 Replies


P: n/a
"Jorge Peixoto de Morais Neto" <pl*****************@gmail.comwrites:
I was reading the code of FFmpeg and it seems that they use malloc
just too much. The problems and dangers of malloc are widely known.
[...]
I was thinking that, with C99's variable length arrays, malloc
shouldn't be needed most of the time. But I'm not sure if it is
appropriate to declare everything as automatic variables, specially
for huge variables.
What "dangers" of malloc are alleviated by using variable length
arrays? I suspect that forgetting to deallocate the memory block
is the only one.
--
Ben Pfaff
bl*@cs.stanford.edu
http://benpfaff.org
Feb 20 '07 #2

P: n/a
"Jorge Peixoto de Morais Neto" wrote:
>I was reading the code of FFmpeg and it seems that they use malloc
just too much. The problems and dangers of malloc are widely known.
Malloc also has some overhead (although I don't know what is the
overhead of automatic variable sized arrays, I suspect it is smaller
than that of malloc), although I'm not too worried about it.
There are three different areas where you could talk about malloc's
overhead:

(a) Allocation time: This can be problematic, (in the general case) it
is not deterministic, can change from one pass through a function to
the next, can increase over time as memory becomes fragmented, etc.
Can be partially solved using your own memory allocators.
The time necessary to allocate stack space for local variables can be
zero.
For any particular scenario: Benchmark, measure.

(b) Memory overhead: there is a finite amount of storage associated
with each memory block 'malloced', used for internal bookkeeping.
No such overhead for automatic variables. (In common implementations)
For any particular scenario: Benchmark, measure.

(c) Run-time access overhead. Implementation dependent. For most
common architectures there is no noticeable difference in the time
required to access either, but there could be *huge* differences
either way.
The stack and heap areas (yes, I know they do not officially exist,)
may reside in physical devices with different access speeds, (on-chip
stack vs. heap in external RAM, for example), the CPU instruction set
may have weaker instructions for addressing stack based variables, or
weak instructions for accessing general memory (as when all load/store
operations must go trough a dedicated register that becomes a
bottleneck,) and so on.
(It was common in C compilers for low end 8-bit processors (which
typically have weak relative-addressing instructions) to have a
command line optimization switch that would force them to process all
automatic variables as if they were static.)
For any particular scenario: Benchmark, measure.
>
I was thinking that, with C99's variable length arrays, malloc
shouldn't be needed most of the time.
Assuming C99 features are available. That is not always the case.
>But I'm not sure if it is
appropriate to declare everything as automatic variables, specially
for huge variables.

1-) When is it appropriate to use automatic variables?*
a) Small data sizes.
b) The data should be accessible only by the function in which it
resides or functions called from it.
>2-) If the problem is size, then what is the threshold?**
Depends on the system, can be as low as a few tens of bytes for small
embedded systems.
>*I already know that we should be aware of the duration of the
variable, such as not to use an automatic variable as a buffer inside
a function, and then return the buffer. By the time the function
returns, the buffer is gone.

** Of course, I know this varies. But, given a reasonable system (say,
my Athlon XP 2600+ with 512 MB of RAM) and a reasonable OS (such as
GNU/Linux, and let's also include MS Windows because it is common),
can you give me an order of magnitude?
For any particular scenario: Benchmark, measure.
>PS: I have googled first, and searched within this newsgroup before,
and I only found one previous discussion. It missed the point. People
kept arguing that automatic variables are fixed size, which is not
true anymore.
As mentioned above, it still is in many cases.
People also kept arguing that malloc tells you when
there is not enough memory (by returning NULL) and allows you to do
something. I don't care much about it, since in the vast majority of
cases I just close the program when malloc fails.
Would you like the people writing the code for you car's antilock
brakes to follow that approach?
>I have even written
a wrapper, so I don't have to check the pointer:

inline void *smalloc(size_t size){
void * const ptr=malloc(size);
if (ptr==NULL){
fputs("Function ",stderr);
fputs(__func__,stderr);
fputs(" called malloc and malloc returned NULL.\n",stderr);
perror(NULL);
exit(ENOMEM); // exit ou abort?
} else {
return ptr;
}
}

By the way, in the above case should I have used abort() or is exit()
ok? From the respective manual pages, I can't tell.
Roberto Waltman

[ Please reply to the group,
return address is invalid ]
Feb 20 '07 #3

P: n/a
In article <87************@blp.benpfaff.org>,
Ben Pfaff <bl*@cs.stanford.eduwrote:
>What "dangers" of malloc are alleviated by using variable length
arrays? I suspect that forgetting to deallocate the memory block
is the only one.
And unlike malloc(), variable length arrays don't let you recover when
you run out of memory. Of course, nor do any other kind of auto
variable.

-- Richard

--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Feb 20 '07 #4

P: n/a
Jorge Peixoto de Morais Neto wrote:
I was reading the code of FFmpeg and it seems that they use malloc
just too much. The problems and dangers of malloc are widely known.
Isn't it a shame the way people just sit on valuable
information others could benefit from? In the thirty years
I've used C, nobody -- NOBODY -- has warned me about the
"widely known" problems and dangers of malloc(). Well, you
learn something new every day.
Malloc also has some overhead (although I don't know what is the
overhead of automatic variable sized arrays, I suspect it is smaller
than that of malloc), although I'm not too worried about it.

I was thinking that, with C99's variable length arrays, malloc
shouldn't be needed most of the time. But I'm not sure if it is
appropriate to declare everything as automatic variables, specially
for huge variables.

1-) When is it appropriate to use automatic variables?*
When their duration fits the problem at hand, when they're
not unusually large, and when you know the total size at the
point of creation -- i.e., when you won't need realloc().
2-) If the problem is size, then what is the threshold?**
How high is "up?" How long is a piece of string? Or, in
more program-centric terms, how deep is the call stack?

Note that automatic variables might not reside on a stack;
smallish variables are often found in CPU registers, for example.
It's also possible that some VLA implementations just call malloc()
and free() under the covers.
*I already know that we should be aware of the duration of the
variable, such as not to use an automatic variable as a buffer inside
a function, and then return the buffer. By the time the function
returns, the buffer is gone.

** Of course, I know this varies. But, given a reasonable system (say,
my Athlon XP 2600+ with 512 MB of RAM) and a reasonable OS (such as
GNU/Linux, and let's also include MS Windows because it is common),
can you give me an order of magnitude?
As you say, "this varies." A few hundred bytes' worth of
auto variables are usually nothing to worry about; at a few KB
one should spend at least a while thinking about stack depth
(both above and below the current function); at a few tens of
KB and above it would seem more prudent to malloc().
PS: I have googled first, and searched within this newsgroup before,
and I only found one previous discussion. It missed the point. People
kept arguing that automatic variables are fixed size, which is not
true anymore. People also kept arguing that malloc tells you when
there is not enough memory (by returning NULL) and allows you to do
something. I don't care much about it, since in the vast majority of
cases I just close the program when malloc fails.
Even if all you're going to do is shut down, it's often
preferable to do a clean shutdown via exit() than to let the
host environment just rip the rug from beneath you. Would you
like the output streams flushed? Would you like the atexit()
handlers to run? If you're in an airplane, would you rather
hear the pilot say "We're running out of fuel, so we'll have
to divert to Dubuque" or "We're running out of fuel, so I'll
just dive 'er into the sod?"
I have even written
a wrapper, so I don't have to check the pointer:

inline void *smalloc(size_t size){
void * const ptr=malloc(size);
if (ptr==NULL){
Should be `ptr==NULL && size>0'.
fputs("Function ",stderr);
fputs(__func__,stderr);
fputs(" called malloc and malloc returned NULL.\n",stderr);
perror(NULL);
The `errno' value (if there was one that meant anything) may
not have survived through all those fputs() calls.
exit(ENOMEM); // exit ou abort?
Seems a poor choice of exit status (only 0, EXIT_SUCCESS,
and EXIT_FAILURE are standardized; ENOMEM looks like an `errno'
value, not like an exit status). Despite the dubious status,
though, observe the huge difference between calling exit() and
dying without a chance to "get your affairs in order."
} else {
return ptr;
}
}

By the way, in the above case should I have used abort() or is exit()
ok? From the respective manual pages, I can't tell.
It depends on the needs of the program. exit() is usually
preferable, because it will try to run atexit() handlers, flush
output streams, and so on. But if you've really run the memory
tank down to empty, a "clean" shutdown may require more than is
left -- in which case, abort() might be better.

Note that terminating on malloc() failure is not always the
only or even the best strategy available. Imagine: You are using
an editing program, and have been getting things Just Right for
the last three hours. Then you tell it to open this one last
video clip you want to use, and it goes SorryNoMemoryGoodbyeBANG!
and exits with your three hours' labor lost. Wouldn't you have
preferred that it said SorryNoMemory and kept on running, giving
you a chance to save your work?

--
Eric Sosman
es*****@acm-dot-org.invalid
Feb 20 '07 #5

P: n/a
On Feb 20, 2:47 pm, Ben Pfaff <b...@cs.stanford.eduwrote:
"Jorge Peixoto de Morais Neto" <please.no.spam.h...@gmail.comwrites:
I was reading the code of FFmpeg and it seems that they use malloc
just too much. The problems and dangers of malloc are widely known.
[...]
I was thinking that, with C99's variable length arrays, malloc
shouldn't be needed most of the time. But I'm not sure if it is
appropriate to declare everything as automatic variables, specially
for huge variables.

What "dangers" of malloc are alleviated by using variable length
arrays? I suspect that forgetting to deallocate the memory block
is the only one.
malloc returns a pointer. A variable length array, is still just
that; an array. So the common danger of using pointers versus arrays
is removed. (An array base cannot be NULL, cannot change relative to
its intended storage, and cannot be pointing to unaccessible memory.)

It also introduces a new form of risk, however. If there is no space
for such an auto array, then the program clearly exhibits UB. This is
unlike the usual circumstance for "stack overflow" due to recursion,
because those are usually quite easily debuggable. In the variable
length array case, things are arbitrarily hard because the length of
the array chosen is under runtime control.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Feb 20 '07 #6

P: n/a
On Feb 20, 2:37 pm, "Jorge Peixoto de Morais Neto" wrote:
I was reading the code of FFmpeg and it seems that they use malloc
just too much. The problems and dangers of malloc are widely known.
Malloc also has some overhead (although I don't know what is the
overhead of automatic variable sized arrays, I suspect it is smaller
than that of malloc), although I'm not too worried about it.
In my experience, malloc + free takes an estimated total time of about
100 cycles. A compile time variable length array (such as through
C99's variable length arrays, or the function alloca() that some C
compilers support) takes about 1 or 2 total clocks to allocate then
release. So variable length arrays are certainly much faster.
I was thinking that, with C99's variable length arrays, malloc
shouldn't be needed most of the time. But I'm not sure if it is
appropriate to declare everything as automatic variables, specially
for huge variables.
C99 is a generally unrecognized, and effectively obsolete standard.
Using C99, except in limited environments and usually a restricted
subset, is possible but will almost always work against porting of
your code to other platforms.
1-) When is it appropriate to use automatic variables?*
Whenever the lifetime of the variable is equal to the scope of the
code block or function, and when the variable size is fixed at compile
time.
2-) If the problem is size, then what is the threshold?**
Even in C99 this threshold is unknown. No exceptions are thrown, no
error path, no nothing. Your just experience UB if you get it wrong.
*I already know that we should be aware of the duration of the
variable, such as not to use an automatic variable as a buffer inside
a function, and then return the buffer. By the time the function
returns, the buffer is gone.
Well yeah, that's the *major* criteria. If you variable doesn't need
to be returned (and thus is unreferenced), then make it local.
** Of course, I know this varies. But, given a reasonable system (say,
my Athlon XP 2600+ with 512 MB of RAM) and a reasonable OS (such as
GNU/Linux, and let's also include MS Windows because it is common),
can you give me an order of magnitude?
Well, most x86 compilers size the stack by criteria that is determined
by your compiler, not your underlying platform capabilities.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Feb 20 '07 #7

P: n/a
Jorge Peixoto de Morais Neto said:
I was reading the code of FFmpeg and it seems that they use malloc
just too much.
If that is true, then it's a Bad Thing, on the basis that too much of
*anything* is a bad thing. But what makes you think they are using
malloc too much? What criteria are you using to make your judgement?
The problems and dangers of malloc are widely known.
The problems and dangers of malloc *misuse* are widely known, certainly.
Malloc also has some overhead (although I don't know what is the
overhead of automatic variable sized arrays, I suspect it is smaller
than that of malloc),
To which implementations does your suspicion apply, and why?
although I'm not too worried about it.
Oh, that's all right then.
I was thinking that, with C99's variable length arrays, malloc
shouldn't be needed most of the time.
C99 may be here in theory, but it'll be a while yet before it's as
widely available as C90. In any case, VLAs don't solve the problem of
building dynamic data structures that can persist after a function has
returned. Since that's 99.054% (warning: bogus statistic) of all malloc
usage, I don't think we can get rid of malloc that easily. Nor do I see
any particularly strong motivation for doing so.

<snip>
People also kept arguing that malloc tells you when
there is not enough memory (by returning NULL) and allows you to do
something. I don't care much about it, since in the vast majority of
cases I just close the program when malloc fails.
No attempt at recovery? No attempt to save user data? No opportunity for
the user to close some other programs and re-try? Ouch.
I have even written
a wrapper, so I don't have to check the pointer:
Remind me never to use your software. :-)

>
inline void *smalloc(size_t size){
void * const ptr=malloc(size);
if (ptr==NULL){
fputs("Function ",stderr);
fputs(__func__,stderr);
fputs(" called malloc and malloc returned NULL.\n",stderr);
perror(NULL);
exit(ENOMEM); // exit ou abort?
} else {
return ptr;
}
}

By the way, in the above case should I have used abort() or is exit()
ok? From the respective manual pages, I can't tell.
What advantage would abort() confer that exit() doesn't give you?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Feb 20 '07 #8

P: n/a

Jorge Peixoto de Morais Neto wrote:
I was reading the code of FFmpeg and it seems that they use malloc
just too much. The problems and dangers of malloc are widely known.
All techniques have their share of imperfections.
Malloc also has some overhead (although I don't know what is the
overhead of automatic variable sized arrays, I suspect it is smaller
than that of malloc), although I'm not too worried about it.
The Standard doesn't specify anything about the efficiency of a C
construct.
I was thinking that, with C99's variable length arrays, malloc
shouldn't be needed most of the time. But I'm not sure if it is
appropriate to declare everything as automatic variables, specially
for huge variables.
VLA are local objects. More importantly they're not supported well by
most popular C compilers.
1-) When is it appropriate to use automatic variables?*
They'd be appropriate whenever you need relatively small amounts of
storage and will only be using it from a well restricted part of your
entire programme. In other words, they would be called for whenever
you *don't* need wide access, (or scope), and a long lifetime.
2-) If the problem is size, then what is the threshold?**
That would depend upon the specific implementation and target runtime
environment. There's no clear answer. Generally above a few thousand
bytes of storage, you might want to look towards dynamically allocated
memory.

Note though that there's nothing inherent in C's specifications of
automatic objects that restricts their use for large allocation
requests. It is the stack related limitation of many widely used
architectures that make very large automatic objects infeasable or
atleast suspect.

If an implementation happens to have hundreds of megabytes set aside
for automatic objects storage, then there would be no such problems.
*I already know that we should be aware of the duration of the
variable, such as not to use an automatic variable as a buffer inside
a function, and then return the buffer. By the time the function
returns, the buffer is gone.

** Of course, I know this varies. But, given a reasonable system (say,
my Athlon XP 2600+ with 512 MB of RAM) and a reasonable OS (such as
GNU/Linux, and let's also include MS Windows because it is common),
can you give me an order of magnitude?
No. What's reasonable for one situation may not be reasonable for
another. It more important to write modularised C code than worry
about borderline situations. If you find yourself needing very large
automatic objects, (many megabytes), then you should probably rethink
the overall design of your program.
PS: I have googled first, and searched within this newsgroup before,
and I only found one previous discussion. It missed the point. People
kept arguing that automatic variables are fixed size, which is not
true anymore. People also kept arguing that malloc tells you when
there is not enough memory (by returning NULL) and allows you to do
something. I don't care much about it, since in the vast majority of
cases I just close the program when malloc fails. I have even written
a wrapper, so I don't have to check the pointer:

inline void *smalloc(size_t size){
inline would probably gain nothing.
void * const ptr=malloc(size);
It'd make more sense to make size const than ptr.
if (ptr==NULL){
fputs("Function ",stderr);
fputs(__func__,stderr);
fputs(" called malloc and malloc returned NULL.\n",stderr);
perror(NULL);
You should set errno to zero before call to malloc and use perror
before the various fputs calls or save the errno value set by malloc
locally before calling any other function. Also note that the standard
does not require malloc to set errno at all.
exit(ENOMEM); // exit ou abort?
This is a non-standard error value. Additionally other than 0,
EXIT_SUCCESS or EXIT_FAILURE, passing any other value to exit or a
return from main is not portable.
} else {
return ptr;
}
}

By the way, in the above case should I have used abort() or is exit()
ok? From the respective manual pages, I can't tell.
In general if you have no clean-up to do, i.e. all streams are closed
etc., then abort would probably be acceptable. Note that exit calls
functions registered with atexit so if you want to terminate with
executing as little code as possible, then abort is ideal.

In most situations though exit is preferrable, as you get a chance to
properly close resources.

Feb 20 '07 #9

P: n/a
On Feb 20, 2:37 pm, "Jorge Peixoto de Morais Neto"
<please.no.spam.h...@gmail.comwrote:
I was reading the code of FFmpeg and it seems that they use malloc
just too much. The problems and dangers of malloc are widely known.
Malloc also has some overhead (although I don't know what is the
overhead of automatic variable sized arrays, I suspect it is smaller
than that of malloc), although I'm not too worried about it.

I was thinking that, with C99's variable length arrays, malloc
shouldn't be needed most of the time. But I'm not sure if it is
appropriate to declare everything as automatic variables, specially
for huge variables.

1-) When is it appropriate to use automatic variables?*

2-) If the problem is size, then what is the threshold?**

*I already know that we should be aware of the duration of the
variable, such as not to use an automatic variable as a buffer inside
a function, and then return the buffer. By the time the function
returns, the buffer is gone.

** Of course, I know this varies. But, given a reasonable system (say,
my Athlon XP 2600+ with 512 MB of RAM) and a reasonable OS (such as
GNU/Linux, and let's also include MS Windows because it is common),
can you give me an order of magnitude?

PS: I have googled first, and searched within this newsgroup before,
and I only found one previous discussion. It missed the point. People
kept arguing that automatic variables are fixed size, which is not
true anymore. People also kept arguing that malloc tells you when
there is not enough memory (by returning NULL) and allows you to do
something. I don't care much about it, since in the vast majority of
cases I just close the program when malloc fails. I have even written
a wrapper, so I don't have to check the pointer:

inline void *smalloc(size_t size){
void * const ptr=malloc(size);
if (ptr==NULL){
fputs("Function ",stderr);
fputs(__func__,stderr);
fputs(" called malloc and malloc returned NULL.\n",stderr);
perror(NULL);
exit(ENOMEM); // exit ou abort?
} else {
return ptr;
}

}

By the way, in the above case should I have used abort() or is exit()
Usually you only use abort() when you want to use the debugger with
it. You normally use exit() when your program cannot continue. Which
brings up an interesting question.
"What happens to your application when there is insufficient memory
for the auto allocation of the variable sized array?"
I have searched through the standard for the terms "VLA" and "variable
length array" and I do not see anything that spells out what happens
when automatic memory is exhausted.
I suspect very much that the result is simply a crash or a core dump.

So the use of VLA seems to be chiefly trading our forgetfullness to
remember to free the objects we have created for instability and a
situation that is hard to diagnose and recover from.

I was keen on them (VLAs) for a while and then it occurred to me that
the fundamental approach is severely broken. We don't have any way to
recover from a failed VLA allocation. We can at least diagnose the
problem with malloc(). If VLAs could "fail over" and use memory from
the free store when automatic memory is exhausted, they would be a lot
more useful.
ok? From the respective manual pages, I can't tell.
If you are debugging a problem, use abort(). If you are exiting the
program because you have found an error that is too serious to
continue, then use exit().

IMO-YMMV.

Feb 20 '07 #10

P: n/a
On Feb 20, 3:27 pm, Eric Sosman <esos...@acm-dot-org.invalidwrote:
Jorge Peixoto de Morais Neto wrote:
I was reading the code of FFmpeg and it seems that they use malloc
just too much. The problems and dangers of malloc are widely known.

Isn't it a shame the way people just sit on valuable
information others could benefit from? In the thirty years
I've used C, nobody -- NOBODY -- has warned me about the
"widely known" problems and dangers of malloc(). Well, you
learn something new every day.
You, of course, have never heard of viruses, heap overflows, double
freeing, memory leaking or information leaking. Probably because
these things don't appear in the standard and you haven't looked at
the wider world of computing since the 1970s.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Feb 20 '07 #11

P: n/a
> Isn't it a shame the way people just sit on valuable
>information others could benefit from? In the thirty years
I've used C, nobody -- NOBODY -- has warned me about the
"widely known" problems and dangers of malloc(). Well, you
learn something new every day.

You, of course, have never heard of viruses, heap overflows, double
freeing, memory leaking or information leaking. Probably because
these things don't appear in the standard and you haven't looked at
the wider world of computing since the 1970s.
And using auto arrays (especially variable-size and large) can have
problems with viruses, stack (if there is one) frame overflows,
information leaking, and stack overflow. Stack-frame-clobbering
is more popular with viruses than malloc-region-clobbering since
clobbering the return address can force a branch to someplace
specified by the virus but malloc-region-clobbering isn't guaranteed
to do that. At least with malloc() calls, it's possible to check
if you ran out of memory.
Feb 21 '07 #12

P: n/a
we******@gmail.com writes:
On Feb 20, 2:47 pm, Ben Pfaff <b...@cs.stanford.eduwrote:
>"Jorge Peixoto de Morais Neto" <please.no.spam.h...@gmail.comwrites:
I was reading the code of FFmpeg and it seems that they use malloc
just too much. The problems and dangers of malloc are widely known.
[...]
I was thinking that, with C99's variable length arrays, malloc
shouldn't be needed most of the time. But I'm not sure if it is
appropriate to declare everything as automatic variables, specially
for huge variables.

What "dangers" of malloc are alleviated by using variable length
arrays? I suspect that forgetting to deallocate the memory block
is the only one.

malloc returns a pointer. A variable length array, is still just
that; an array. So the common danger of using pointers versus arrays
is removed. (An array base cannot be NULL, cannot change relative to
its intended storage, and cannot be pointing to unaccessible memory.)
[...]

I fail to see how any danger is removed. An array name still decays
to a pointer in most contexts, and all the pitfalls of confusing
arrays and pointers (all of which can be alleviated by reading and
understanding section 6 of the comp.lang.c FAQ) are still there.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 21 '07 #13

P: n/a
we******@gmail.com wrote:
Eric Sosman <esos...@acm-dot-org.invalidwrote:
>Jorge Peixoto de Morais Neto wrote:
>>I was reading the code of FFmpeg and it seems that they use
malloc just too much. The problems and dangers of malloc are
widely known.

Isn't it a shame the way people just sit on valuable information
others could benefit from? In the thirty years I've used C,
nobody -- NOBODY -- has warned me about the "widely known"
problems and dangers of malloc(). Well, you learn something new
every day.

You, of course, have never heard of viruses, heap overflows,
double freeing, memory leaking or information leaking. Probably
because these things don't appear in the standard and you haven't
looked at the wider world of computing since the 1970s.
I see you have been taking diplomacy lessons from Dan Pop, so you
should know where he has gone, and why he is no longer active
here. Please tell us all.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
Feb 21 '07 #14

P: n/a
People also kept arguing that malloc tells you when
there is not enough memory (by returning NULL) and allows you to do
something. I don't care much about it, since in the vast majority of
cases I just close the program when malloc fails.

Would you like the people writing the code for you car's antilock
brakes to follow that approach?
Good example. It reminds that a wrapper like mine should not be
blindly used. I still think it is OK to use in a lot of circustances,
though, as long as you know what you are doing.

And for the many people that said that my wrapper would do a dirty
exit: the exit() function does a lot of cleanup automatically: flushes
and closes files, removes tmpfile() temp files, executes functions
registered with atexit() and on_exit()... (this is straight from the
man page). So, I do think that in that majority of cases the wrapper
(with the corrections people suggested) is OK. Again, it should not be
blindingly used. The guy who talked about the editing program gave an
excellent example.

Oh, and thak you very much for all the responses.

Feb 21 '07 #15

P: n/a
On 20 fev, 22:39, "Jorge Peixoto de Morais Neto"
<please.no.spam.h...@gmail.comwrote:
People also kept arguing that malloc tells you when
>there is not enough memory (by returning NULL) and allows you to do
>something. I don't care much about it, since in the vast majority of
>cases I just close the program when malloc fails.
Would you like the people writing the code for you car's antilock
brakes to follow that approach?

Good example. It reminds that a wrapper like mine should not be
blindly used. I still think it is OK to use in a lot of circustances,
though, as long as you know what you are doing.

And for the many people that said that my wrapper would do a dirty
exit: the exit() function does a lot of cleanup automatically: flushes
and closes files, removes tmpfile() temp files, executes functions
registered with atexit() and on_exit()... (this is straight from the
man page). So, I do think that in that majority of cases the wrapper
(with the corrections people suggested) is OK. Again, it should not be
blindingly used. The guy who talked about the editing program gave an
excellent example.

Oh, and thak you very much for all the responses.
Oh, and to make clear, I am aware that, since the program will crash
when I use too much stack, than I should not use huge variables on
stack unless I'm OK with the program crashing if there is not enough
memory. So if it would be OK to use the wrapper, it is OK to use VLA.
(from the "what happens if it crash" perspective. There are still
other perspectives.)

If I'm encoding video and there is not enough memory for and important
buffer, I can only flush the buffers, close the files and exit. The
wrapper is OK.

In the case of the antilock brake though, it is not OK.

Feb 21 '07 #16

P: n/a
On 20 fev, 20:27, Eric Sosman <esos...@acm-dot-org.invalidwrote:
Jorge Peixoto de Morais Neto wrote:
I was reading the code of FFmpeg and it seems that they use malloc
just too much. The problems and dangers of malloc are widely known.

Isn't it a shame the way people just sit on valuable
information others could benefit from? In the thirty years
I've used C, nobody -- NOBODY -- has warned me about the
"widely known" problems and dangers of malloc(). Well, you
learn something new every day.
Malloc also has some overhead (although I don't know what is the
overhead of automatic variable sized arrays, I suspect it is smaller
than that of malloc), although I'm not too worried about it.
I was thinking that, with C99's variable length arrays, malloc
shouldn't be needed most of the time. But I'm not sure if it is
appropriate to declare everything as automatic variables, specially
for huge variables.
1-) When is it appropriate to use automatic variables?*

When their duration fits the problem at hand, when they're
not unusually large, and when you know the total size at the
point of creation -- i.e., when you won't need realloc().
2-) If the problem is size, then what is the threshold?**

How high is "up?" How long is a piece of string? Or, in
more program-centric terms, how deep is the call stack?

Note that automatic variables might not reside on a stack;
smallish variables are often found in CPU registers, for example.
It's also possible that some VLA implementations just call malloc()
and free() under the covers.
*I already know that we should be aware of the duration of the
variable, such as not to use an automatic variable as a buffer inside
a function, and then return the buffer. By the time the function
returns, the buffer is gone.
** Of course, I know this varies. But, given a reasonable system (say,
my Athlon XP 2600+ with 512 MB of RAM) and a reasonable OS (such as
GNU/Linux, and let's also include MS Windows because it is common),
can you give me an order of magnitude?

As you say, "this varies." A few hundred bytes' worth of
auto variables are usually nothing to worry about; at a few KB
one should spend at least a while thinking about stack depth
(both above and below the current function); at a few tens of
KB and above it would seem more prudent to malloc().
PS: I have googled first, and searched within this newsgroup before,
and I only found one previous discussion. It missed the point. People
kept arguing that automatic variables are fixed size, which is not
true anymore. People also kept arguing that malloc tells you when
there is not enough memory (by returning NULL) and allows you to do
something. I don't care much about it, since in the vast majority of
cases I just close the program when malloc fails.

Even if all you're going to do is shut down, it's often
preferable to do a clean shutdown via exit() than to let the
host environment just rip the rug from beneath you. Would you
like the output streams flushed? Would you like the atexit()
handlers to run? If you're in an airplane, would you rather
hear the pilot say "We're running out of fuel, so we'll have
to divert to Dubuque" or "We're running out of fuel, so I'll
just dive 'er into the sod?"
Good point.
When I told that "If there is no memory, just let it crash" I was
think of applications like video encoding. If, at the beginning of the
encoding, a buffer cannot be allocated, the program should just exit,
and I don't care about cleanup (since we have no useful data to be
flushed). But of course, I wouldn't do this in the main encoding loop,
since there may be useful data to be flushed, so I should call exit.
Heck, it may happen that he program runs out of memory in the very
last frame of the video...

I was thinking about a specific case and spoke like if was the general
case. Sorry about that.
>
I have even written
a wrapper, so I don't have to check the pointer:
inline void *smalloc(size_t size){
void * const ptr=malloc(size);
if (ptr==NULL){

Should be `ptr==NULL && size>0'.
fputs("Function ",stderr);
fputs(__func__,stderr);
fputs(" called malloc and malloc returned NULL.\n",stderr);
perror(NULL);

The `errno' value (if there was one that meant anything) may
not have survived through all those fputs() calls.
I had read about it today but forgot when writing the wrapper...
Thanks for reminding me
>
exit(ENOMEM); // exit ou abort?

Seems a poor choice of exit status (only 0, EXIT_SUCCESS,
and EXIT_FAILURE are standardized; ENOMEM looks like an `errno'
value, not like an exit status).
Forgive my ignorance, but so what i
Despite the dubious status,
though, observe the huge difference between calling exit() and
dying without a chance to "get your affairs in order."
} else {
return ptr;
}
}
By the way, in the above case should I have used abort() or is exit()
ok? From the respective manual pages, I can't tell.

It depends on the needs of the program. exit() is usually
preferable, because it will try to run atexit() handlers, flush
output streams, and so on. But if you've really run the memory
tank down to empty, a "clean" shutdown may require more than is
left -- in which case, abort() might be better.

Note that terminating on malloc() failure is not always the
only or even the best strategy available. Imagine: You are using
an editing program, and have been getting things Just Right for
the last three hours. Then you tell it to open this one last
video clip you want to use, and it goes SorryNoMemoryGoodbyeBANG!
and exits with your three hours' labor lost. Wouldn't you have
preferred that it said SorryNoMemory and kept on running, giving
you a chance to save your work?

--
Eric Sosman
esos...@acm-dot-org.invalid

Feb 21 '07 #17

P: n/a
On 20 fev, 21:07, gordonb.lp...@burditt.org (Gordon Burditt) wrote:
Isn't it a shame the way people just sit on valuable
information others could benefit from? In the thirty years
I've used C, nobody -- NOBODY -- has warned me about the
"widely known" problems and dangers of malloc(). Well, you
learn something new every day.
You, of course, have never heard of viruses, heap overflows, double
freeing, memory leaking or information leaking. Probably because
these things don't appear in the standard and you haven't looked at
the wider world of computing since the 1970s.

And using auto arrays (especially variable-size and large) can have
problems with viruses, stack (if there is one) frame overflows,
information leaking, and stack overflow. Stack-frame-clobbering
is more popular with viruses than malloc-region-clobbering since
clobbering the return address can force a branch to someplace
specified by the virus but malloc-region-clobbering isn't guaranteed
to do that. At least with malloc() calls, it's possible to check
if you ran out of memory.
He meant that malloc has some dangers, not that VLAs do not.

Feb 21 '07 #18

P: n/a
exit(ENOMEM); // exit ou abort?
>
Seems a poor choice of exit status (only 0, EXIT_SUCCESS,
and EXIT_FAILURE are standardized; ENOMEM looks like an `errno'
value, not like an exit status).

Forgive my ignorance, but so what i
I hit "send" too soon. Forget the last sentence.

Feb 21 '07 #19

P: n/a
>
Note that terminating on malloc() failure is not always the
only or even the best strategy available. Imagine: You are using
an editing program, and have been getting things Just Right for
the last three hours. Then you tell it to open this one last
video clip you want to use, and it goes SorryNoMemoryGoodbyeBANG!
and exits with your three hours' labor lost. Wouldn't you have
preferred that it said SorryNoMemory and kept on running, giving
you a chance to save your work?
You made me think of another question: when a program crashes,
possibly due to lack of memory, do the OS normally flush its buffers
and close its files?

Feb 21 '07 #20

P: n/a
"Jorge Peixoto de Morais Neto" <pl*****************@gmail.comwrites:
[...]
Oh, and to make clear, I am aware that, since the program will crash
when I use too much stack, than I should not use huge variables on
stack unless I'm OK with the program crashing if there is not enough
memory. So if it would be OK to use the wrapper, it is OK to use VLA.
(from the "what happens if it crash" perspective. There are still
other perspectives.)
[...]

You're assuming that the program will "crash" if you attempt to
allocate too much memory with a VLA. The standard doesn't guarantee
this; it says only that the behavior is undefined. (Actually, I don't
think it even says that, but it's implicit in the lack of definition
of the behavior.) The consequences of undefined behavior can be
arbitrarily horrific, including having the program continue to run and
give bad results with no visible indication that anything has gone
wrong.

Now it's very likely that a "stack overflow" will be caught by the OS,
and will cause the program to do nothing more drastic than terminating
immediately. But the standard doens't guarantee this.

Of course, all this applies to fixed-size automatic variables just as
much as to VLAs. VLAs tend to be more dangerous, though, because of
the risk of computing the needed size incorrectly.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 21 '07 #21

P: n/a
On Feb 20, 6:09 pm, "Jorge Peixoto de Morais Neto"
<please.no.spam.h...@gmail.comwrote:
On 20 fev, 21:07, gordonb.lp...@burditt.org (Gordon Burditt) wrote:
> Isn't it a shame the way people just sit on valuable
>information others could benefit from? In the thirty years
>I've used C, nobody -- NOBODY -- has warned me about the
>"widely known" problems and dangers of malloc(). Well, you
>learn something new every day.
>You, of course, have never heard of viruses, heap overflows, double
>freeing, memory leaking or information leaking. Probably because
>these things don't appear in the standard and you haven't looked at
>the wider world of computing since the 1970s.
And using auto arrays (especially variable-size and large) can have
problems with viruses, stack (if there is one) frame overflows,
information leaking, and stack overflow. Stack-frame-clobbering
is more popular with viruses than malloc-region-clobbering since
clobbering the return address can force a branch to someplace
specified by the virus but malloc-region-clobbering isn't guaranteed
to do that. At least with malloc() calls, it's possible to check
if you ran out of memory.

He meant that malloc has some dangers, not that VLAs do not.
The only danger malloc() has that VLA does not is that you do not have
to remember to free a VLA.
Every other flaw that malloc has, VLAs also have.
On the other hand, VLAs have fatal flaws that are far in excess of
what malloc() has.
What will your program do when it asks for a VLA but your program is
all out of automatic memory?
There are also some subtle things like alignment. The memory
allocated by malloc() must have suitable alignment for any sort of
object. I see no such guarantee on a VLA. So I see in this a subtle
opportunity for bus errors.

In short, what does a VLA buy for you?
You don't have to remember to call free (but it also means that you
will not get persistence that can last outside of a block).
You get memory from the automatic memory area instead of the free
store (which might be faster but also might have alignment only for
the array type at hand).

What't the big danger of a VLA:
When the allocation fails, the airplane goes out of control. It
enters your living room, and strikes you on the back of the head while
you are watching 'The Simpsons'. It flies out of your left nostril,
leaving your brains in a rather disheveled state.
Maybe : "Low on memory -- you'll have to play pong later" would have
been better.

Feb 21 '07 #22

P: n/a
On 20 fev, 23:27, "Jorge Peixoto de Morais Neto"
<please.no.spam.h...@gmail.comwrote:
Note that terminating on malloc() failure is not always the
only or even the best strategy available. Imagine: You are using
an editing program, and have been getting things Just Right for
the last three hours. Then you tell it to open this one last
video clip you want to use, and it goes SorryNoMemoryGoodbyeBANG!
and exits with your three hours' labor lost. Wouldn't you have
preferred that it said SorryNoMemory and kept on running, giving
you a chance to save your work?

You made me think of another question: when a program crashes,
possibly due to lack of memory, do the OS normally flush its buffers
and close its files?
Answering myself: I have just tested, and it seems I can have a singe
2 MB automatic variable. It seems that when the program crashes the OS
does *not* flush its buffers.

Interestingly, it seems I can allocate several 2 MB variables. So the
problem is if I try to allocate too much space at once. Several 2 MB
variables seem to be possible.

Feb 21 '07 #23

P: n/a
On 20 fev, 23:55, "Jorge Peixoto de Morais Neto"
<please.no.spam.h...@gmail.comwrote:
On 20 fev, 23:27, "Jorge Peixoto de Morais Neto"

<please.no.spam.h...@gmail.comwrote:
Note that terminating on malloc() failure is not always the
only or even the best strategy available. Imagine: You are using
an editing program, and have been getting things Just Right for
the last three hours. Then you tell it to open this one last
video clip you want to use, and it goes SorryNoMemoryGoodbyeBANG!
and exits with your three hours' labor lost. Wouldn't you have
preferred that it said SorryNoMemory and kept on running, giving
you a chance to save your work?
You made me think of another question: when a program crashes,
possibly due to lack of memory, do the OS normally flush its buffers
and close its files?

Answering myself: I have just tested, and it seems I can have a singe
2 MB automatic variable. It seems that when the program crashes the OS
does *not* flush its buffers.

Interestingly, it seems I can allocate several 2 MB variables. So the
problem is if I try to allocate too much space at once. Several 2 MB
variables seem to be possible.
I'm sorry, the test was broken. It seems that the program crashes
whenever the total size for the locals is greater than 2MB. I can't
allocate two 1.5 MB variables.

Feb 21 '07 #24

P: n/a
On Feb 20, 8:55 pm, "Jorge Peixoto de Morais Neto"
<please.no.spam.h...@gmail.comwrote:
You made me think of another question: when a program crashes,
possibly due to lack of memory, do the OS normally flush its buffers
and close its files?

Answering myself: I have just tested, and it seems I can have a singe
2 MB automatic variable. It seems that when the program crashes the OS
does *not* flush its buffers.

While the answer to your question is entirely OS dependant, it's quite
likely that you've misunderstood what happening in your OS. Almost
all OS's *will* flush *their* buffers when an application crashes (or
at least no discard them so that the get written to disk based on
whatever the OS's dirty write policy is). What you've forgotten is
that streams in C almost always implement their own buffering (that's
what's modified by setvbuf() and friends) on top of whatever the OS
might be doing. Those do *not* get flushed by the OS when the
application crashes, since they are not actually visible to the OS.
Retry your test with an unbuffered stream.

Feb 21 '07 #25

P: n/a
On Feb 20, 6:55 pm, "Jorge Peixoto de Morais Neto"
<please.no.spam.h...@gmail.comwrote:
On 20 fev, 23:27, "Jorge Peixoto de Morais Neto"

<please.no.spam.h...@gmail.comwrote:
Note that terminating on malloc() failure is not always the
only or even the best strategy available. Imagine: You are using
an editing program, and have been getting things Just Right for
the last three hours. Then you tell it to open this one last
video clip you want to use, and it goes SorryNoMemoryGoodbyeBANG!
and exits with your three hours' labor lost. Wouldn't you have
preferred that it said SorryNoMemory and kept on running, giving
you a chance to save your work?
You made me think of another question: when a program crashes,
possibly due to lack of memory, do the OS normally flush its buffers
and close its files?

Answering myself: I have just tested, and it seems I can have a singe
2 MB automatic variable. It seems that when the program crashes the OS
does *not* flush its buffers.

Interestingly, it seems I can allocate several 2 MB variables. So the
problem is if I try to allocate too much space at once. Several 2 MB
variables seem to be possible.
You can't find the answers to questions like this very well by
experimentation.
A different compiler can have a different result.
A different machine can have a different result.
You can modify the programs stack, even after linking (on some
systems).
A change in compiler settings can turn off stack overflow detection
(and now you're really in trouble).
A a different compiler may not have stack overflow detection (and now
you're really in trouble).

Unfortunately, there is no elegant way to catch VLA allocation errors
and there is no way to reliably expect or detect them either.
You could do the old 'stack address subtraction' trick, but you can't
really {portably} know for sure how much stack is available.

In short, VLAs are a mixed blessing, and a mixed cursing.
Use with care and use with joy. But learn that they are not a toy.
OK, sometimes they're a toy.
Feb 21 '07 #26

P: n/a
On 20 fev, 23:51, "user923005" <dcor...@connx.comwrote:
On Feb 20, 6:09 pm, "Jorge Peixoto de Morais Neto"

<please.no.spam.h...@gmail.comwrote:
On 20 fev, 21:07, gordonb.lp...@burditt.org (Gordon Burditt) wrote:
Isn't it a shame the way people just sit on valuable
information others could benefit from? In the thirty years
I've used C, nobody -- NOBODY -- has warned me about the
"widely known" problems and dangers of malloc(). Well, you
learn something new every day.
You, of course, have never heard of viruses, heap overflows, double
freeing, memory leaking or information leaking. Probably because
these things don't appear in the standard and you haven't looked at
the wider world of computing since the 1970s.
And using auto arrays (especially variable-size and large) can have
problems with viruses, stack (if there is one) frame overflows,
information leaking, and stack overflow. Stack-frame-clobbering
is more popular with viruses than malloc-region-clobbering since
clobbering the return address can force a branch to someplace
specified by the virus but malloc-region-clobbering isn't guaranteed
to do that. At least with malloc() calls, it's possible to check
if you ran out of memory.
He meant that malloc has some dangers, not that VLAs do not.

The only danger malloc() has that VLA does not is that you do not have
to remember to free a VLA.
Every other flaw that malloc has, VLAs also have.
On the other hand, VLAs have fatal flaws that are far in excess of
what malloc() has.
What will your program do when it asks for a VLA but your program is
all out of automatic memory?
There are also some subtle things like alignment. The memory
allocated by malloc() must have suitable alignment for any sort of
object. I see no such guarantee on a VLA. So I see in this a subtle
opportunity for bus errors.

In short, what does a VLA buy for you?
You don't have to remember to call free (but it also means that you
will not get persistence that can last outside of a block).
You get memory from the automatic memory area instead of the free
store (which might be faster but also might have alignment only for
the array type at hand).

What't the big danger of a VLA:
When the allocation fails, the airplane goes out of control. It
enters your living room, and strikes you on the back of the head while
you are watching 'The Simpsons'. It flies out of your left nostril,
leaving your brains in a rather disheveled state.
Maybe : "Low on memory -- you'll have to play pong later" would have
been better.
I got your point, but I don't see the problem with the alignment
issue. If I declare a VLA of type x, it is guaranteed to be aligned
for type x, is it not? From what I know, malloc is no better than VLA
in this aspect. The only difference is that malloc returns a void*, so
that it must be aligned for anything. A guy told me that malloc does 8-
byte alignment (obviously, this might - and almost certainly will -
differ between systems).

Feb 21 '07 #27

P: n/a
On 21 fev, 00:03, "robertwess...@yahoo.com" <robertwess...@yahoo.com>
wrote:
On Feb 20, 8:55 pm, "Jorge Peixoto de Morais Neto"

<please.no.spam.h...@gmail.comwrote:
You made me think of another question: when a program crashes,
possibly due to lack of memory, do the OS normally flush its buffers
and close its files?
Answering myself: I have just tested, and it seems I can have a singe
2 MB automatic variable. It seems that when the program crashes the OS
does *not* flush its buffers.

While the answer to your question is entirely OS dependant, it's quite
likely that you've misunderstood what happening in your OS. Almost
all OS's *will* flush *their* buffers when an application crashes (or
at least no discard them so that the get written to disk based on
whatever the OS's dirty write policy is). What you've forgotten is
that streams in C almost always implement their own buffering (that's
what's modified by setvbuf() and friends) on top of whatever the OS
might be doing. Those do *not* get flushed by the OS when the
application crashes, since they are not actually visible to the OS.
Retry your test with an unbuffered stream.
When I said "its buffers", I was referring to the user-space stream
buffers. Sorry about that. Ambiguity in the English language. As an
offtopic remark, this kind of thing seems more common in English than
in Portuguese.

Feb 21 '07 #28

P: n/a
On Feb 20, 7:09 pm, "Jorge Peixoto de Morais Neto"
<please.no.spam.h...@gmail.comwrote:
On 20 fev, 23:51, "user923005" <dcor...@connx.comwrote:
On Feb 20, 6:09 pm, "Jorge Peixoto de Morais Neto"
<please.no.spam.h...@gmail.comwrote:
On 20 fev, 21:07, gordonb.lp...@burditt.org (Gordon Burditt) wrote:
> Isn't it a shame the way people just sit on valuable
>information others could benefit from? In the thirty years
>I've used C, nobody -- NOBODY -- has warned me about the
>"widely known" problems and dangers of malloc(). Well, you
>learn something new every day.
>You, of course, have never heard of viruses, heap overflows, double
>freeing, memory leaking or information leaking. Probably because
>these things don't appear in the standard and you haven't looked at
>the wider world of computing since the 1970s.
And using auto arrays (especially variable-size and large) can have
problems with viruses, stack (if there is one) frame overflows,
information leaking, and stack overflow. Stack-frame-clobbering
is more popular with viruses than malloc-region-clobbering since
clobbering the return address can force a branch to someplace
specified by the virus but malloc-region-clobbering isn't guaranteed
to do that. At least with malloc() calls, it's possible to check
if you ran out of memory.
He meant that malloc has some dangers, not that VLAs do not.
The only danger malloc() has that VLA does not is that you do not have
to remember to free a VLA.
Every other flaw that malloc has, VLAs also have.
On the other hand, VLAs have fatal flaws that are far in excess of
what malloc() has.
What will your program do when it asks for a VLA but your program is
all out of automatic memory?
There are also some subtle things like alignment. The memory
allocated by malloc() must have suitable alignment for any sort of
object. I see no such guarantee on a VLA. So I see in this a subtle
opportunity for bus errors.
In short, what does a VLA buy for you?
You don't have to remember to call free (but it also means that you
will not get persistence that can last outside of a block).
You get memory from the automatic memory area instead of the free
store (which might be faster but also might have alignment only for
the array type at hand).
What't the big danger of a VLA:
When the allocation fails, the airplane goes out of control. It
enters your living room, and strikes you on the back of the head while
you are watching 'The Simpsons'. It flies out of your left nostril,
leaving your brains in a rather disheveled state.
Maybe : "Low on memory -- you'll have to play pong later" would have
been better.

I got your point, but I don't see the problem with the alignment
issue. If I declare a VLA of type x, it is guaranteed to be aligned
for type x, is it not? From what I know, malloc is no better than VLA
in this aspect. The only difference is that malloc returns a void*, so
that it must be aligned for anything. A guy told me that malloc does 8-
byte alignment (obviously, this might - and almost certainly will -
differ between systems).
If you do things that evil C programmers are wont to do from time to
time, you might get yourself a bus fault.

For instance, suppose that your cheeky little VLA is being used as a
union because -- hey -- it's clever and it can hold anything smaller
than [dim] bytes. This might cause a bus error:
*myInteger = *(int *) &myVLA;
but it would not if you had used malloc() instead. I agree that it is
esoteric, but that's another difference worth keeping in mind.
Feb 21 '07 #29

P: n/a
On Feb 20, 7:09 pm, "Jorge Peixoto de Morais Neto"
<please.no.spam.h...@gmail.comwrote:
[snip]
A guy told me that malloc does 8-
byte alignment (obviously, this might - and almost certainly will -
differ between systems).
P.S.
It's not 8 bytes. It might be 8 bytes on system x, y, or z. But
there are no guarantees of that. So if you assume it, you could
easily get into trouble.

Memory returned by malloc()/calloc() is "suitably aligned for any data
type" -- and whatever that means is what it is.
Feb 21 '07 #30

P: n/a
On Feb 20, 5:28 pm, Keith Thompson <k...@mib.orgwrote:
websn...@gmail.com writes:
malloc returns a pointer. A variable length array, is still just
that; an array. So the common danger of using pointers versus arrays
is removed. (An array base cannot be NULL, cannot change relative to
its intended storage, and cannot be pointing to unaccessible memory.)

[...]

I fail to see how any danger is removed. An array name still decays
to a pointer in most contexts, and all the pitfalls of confusing
arrays and pointers (all of which can be alleviated by reading and
understanding section 6 of the comp.lang.c FAQ) are still there.
Do you truly have no neurons functioning outside the confines of the
imagined perfect workings of the standard at all? Danger is about
failure -- its about when people do things wrong, and are not reading
or implementing things 100% in accordance to the standard. And it
appears everywhere, because this language highly encourages that sort
of thing. Here's a test for *YOU*. Can you name *ANYTHING* dangerous
at all about the C language? This is just to establish exactly where
your credibility as an intellectual entity is.

A pointer *ITSELF* is storage, which can be modified. By losing track
of this pointer value, logic errors can easily cause you to be
pointing at the wrong thing when you derefence that pointer. This is
the source of danger. An array is actually implicitely determined at
runtime as a nonmutable pointer that is never NULL -- if its auto,
then its usually just an offset relative to a stack register. The
value cannot be modified at all, and its storage lifetime is never in
question or at issue.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Feb 21 '07 #31

P: n/a
we******@gmail.com wrote:
On Feb 20, 3:27 pm, Eric Sosman <esos...@acm-dot-org.invalidwrote:
>Jorge Peixoto de Morais Neto wrote:
>>I was reading the code of FFmpeg and it seems that they use malloc
just too much. The problems and dangers of malloc are widely known.
Isn't it a shame the way people just sit on valuable
information others could benefit from? In the thirty years
I've used C, nobody -- NOBODY -- has warned me about the
"widely known" problems and dangers of malloc(). Well, you
learn something new every day.

You, of course, have never heard of viruses, heap overflows, double
freeing, memory leaking or information leaking. Probably because
these things don't appear in the standard and you haven't looked at
the wider world of computing since the 1970s.
Your abusive language accompanies your failure to provide any sort of
supporting argument. It may surprise you to learn that name-calling
does not count as a rational argument. Nor does your lack of competence
amount to "problems and dangers of malloc." Rather than suggestive
illusory solutions to imaginary problems with malloc, work on learning
how to program competently.
Feb 21 '07 #32

P: n/a
we******@gmail.com wrote:
On Feb 20, 5:28 pm, Keith Thompson <k...@mib.orgwrote:
>websn...@gmail.com writes:
>>malloc returns a pointer. A variable length array, is still just
that; an array. So the common danger of using pointers versus arrays
is removed. (An array base cannot be NULL, cannot change relative to
its intended storage, and cannot be pointing to unaccessible memory.)
[...]

I fail to see how any danger is removed. An array name still decays
to a pointer in most contexts, and all the pitfalls of confusing
arrays and pointers (all of which can be alleviated by reading and
understanding section 6 of the comp.lang.c FAQ) are still there.

Do you truly have no neurons functioning outside the confines of the
imagined perfect workings of the standard at all? Danger is about
failure -- its about when people do things wrong, and are not reading
or implementing things 100% in accordance to the standard. And it
appears everywhere, because this language highly encourages that sort
of thing. Here's a test for *YOU*. Can you name *ANYTHING* dangerous
at all about the C language? This is just to establish exactly where
your credibility as an intellectual entity is.
Your abusive language accompanies your failure to provide any sort of
supporting argument. It may surprise you to learn that name-calling
does not count as a rational argument. Nor does your lack of competence
amount to "problems and dangers of malloc." Rather than suggestive
illusory solutions to imaginary problems with malloc, work on learning
how to program competently.
Feb 21 '07 #33

P: n/a
we******@gmail.com writes:
On Feb 20, 5:28 pm, Keith Thompson <k...@mib.orgwrote:
>websn...@gmail.com writes:
malloc returns a pointer. A variable length array, is still just
that; an array. So the common danger of using pointers versus arrays
is removed. (An array base cannot be NULL, cannot change relative to
its intended storage, and cannot be pointing to unaccessible memory.)

[...]

I fail to see how any danger is removed. An array name still decays
to a pointer in most contexts, and all the pitfalls of confusing
arrays and pointers (all of which can be alleviated by reading and
understanding section 6 of the comp.lang.c FAQ) are still there.

Do you truly have no neurons functioning
[snip]

That's about where I stopped reading. If you can't be civil, I'm just
not interested in what you have to say. It's too bad; there might
have been some interesting technical points in there, but I have
better things to do than wade through your crap.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 21 '07 #34

P: n/a
On Feb 21, 8:33 am, Keith Thompson <k...@mib.orgwrote:
websn...@gmail.com writes:
Do you truly have no neurons functioning

[snip]

That's about where I stopped reading. If you can't be civil, I'm just
not interested in what you have to say. It's too bad; there might
have been some interesting technical points in there, but I have
better things to do than wade through your crap.
There was an interesting technical point, and I'd be quite interested
to hear you and others talk about it, so I'll reproduce websnarf's
post with the gratuitous insults removed:
A pointer *ITSELF* is storage, which can be modified. By losing track of
this pointer value, logic errors can easily cause you to be pointing at the
wrong thing when you derefence that pointer. This is the source of danger.
An array is actually implicitely determined at runtime as a nonmutable
pointer that is never NULL -- if its auto, then its usually just an offset
relative to a stack register. The value cannot be modified at all, and its
storage lifetime is never in question or at issue.
Is an array really equivalent to a non-mutable non-NULL pointer?

Feb 21 '07 #35

P: n/a
tp******@googlemail.com wrote, On 21/02/07 08:51:
On Feb 21, 8:33 am, Keith Thompson <k...@mib.orgwrote:
>websn...@gmail.com writes:
>>Do you truly have no neurons functioning
[snip]

That's about where I stopped reading. If you can't be civil, I'm just
not interested in what you have to say. It's too bad; there might
have been some interesting technical points in there, but I have
better things to do than wade through your crap.

There was an interesting technical point, and I'd be quite interested
to hear you and others talk about it, so I'll reproduce websnarf's
post with the gratuitous insults removed:
>A pointer *ITSELF* is storage, which can be modified. By losing track of
this pointer value, logic errors can easily cause you to be pointing at the
wrong thing when you derefence that pointer. This is the source of danger.
Agreed, although in the situations where a VLA would be a suitable
alternative solution it is, IMHO, easy to ensure you do not make those
mistakes. A quick check that it is non-null after allocation and then
only use array notation on it.
>An array is actually implicitely determined at runtime as a nonmutable
pointer that is never NULL -- if its auto, then its usually just an offset
That is just asking to confuse the less experienced since array and
pointers have very important differences.
>relative to a stack register. The value cannot be modified at all, and its
type * const ptr = malloc(10 * sizeof *ptr);

There, not ptr cannot be modified without you going to a lot of work.
>storage lifetime is never in question or at issue.
Now you just have to remember to free it which is not that difficult in
the situation where a VLA could be used.

So yes, there is more danger of programmer error, but if you are
sensible not much. However, there is more danger of a VLA causing
problems when memory runs short (or you just try for too large an array)
than with malloc because you cannot trap the error.
Is an array really equivalent to a non-mutable non-NULL pointer?
Check the result of applying sizeof to it and you will find out that it
is not. Also the type of &array is not the same as the type of &ptr

Repeat after me, "an array is not a pointer and a pointer is not an
array". Also check out section 6 of the comp.lang.c FAQ.
--
Flash Gordon
Feb 21 '07 #36

P: n/a
tp******@googlemail.com writes:
On Feb 21, 8:33 am, Keith Thompson <k...@mib.orgwrote:
>websn...@gmail.com writes:
Do you truly have no neurons functioning

[snip]

That's about where I stopped reading. If you can't be civil, I'm just
not interested in what you have to say. It's too bad; there might
have been some interesting technical points in there, but I have
better things to do than wade through your crap.

There was an interesting technical point, and I'd be quite interested
to hear you and others talk about it, so I'll reproduce websnarf's
post with the gratuitous insults removed:
>A pointer *ITSELF* is storage, which can be modified. By losing track of
this pointer value, logic errors can easily cause you to be pointing at the
wrong thing when you derefence that pointer. This is the source of danger.
An array is actually implicitely determined at runtime as a nonmutable
pointer that is never NULL -- if its auto, then its usually just an offset
relative to a stack register. The value cannot be modified at all, and its
storage lifetime is never in question or at issue.

Is an array really equivalent to a non-mutable non-NULL pointer?
It depends on what you mean by "pointer".

One common usage is to use the term "pointer" to refer to a pointer
*object*. In that sense, there is no pointer object associated with
an array object.

But if the term "pointer" refers instead to a pointer *value* (the
standard uses the term "pointer" this way), then yes, an array object
implies the existence of a pointer value which is non-mutable and
non-NULL. It is the pointer value to which the array name decays in
most contexts, the address of its first element.

Of course, arrays are not pointers and pointers are not arrays. Most
(but not all) operations on arrays in C are defined in terms of
pointer operations, but it's important to keep in mind that they're
very different things.

And if you've declared an array object, anything you do with it
outside the context in which it's declared (in the case of a VLA, this
is at most a single function) is likely to be done via pointers
anyway, with all the potential for mayhem that that implies.

As for an array object's storage lifetime being "never in question or
at issue", that's true if you know what you're doing, but we see
plenty of functions here that incorrectly attempt to return the
address of a local array object.

I'm not particularly happy with the way C sometimes conflates arrays
and pointers. But the underlying concepts are actually fairly
elegant, in an uncomfortably close-to-the-hardware kind of way. (This
is just my own personal opinion.) Reading and understanding section 6
of the comp.lang.c FAQ is a good way to cope with the confusion.

(This is not to imply that websnarf is or is not aware of all this.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 21 '07 #37

P: n/a
user923005 said:

<snip>
What't the big danger of a VLA:
When the allocation fails, the airplane goes out of control. It
enters your living room, and strikes you on the back of the head while
you are watching 'The Simpsons'. It flies out of your left nostril,
leaving your brains in a rather disheveled state.
Moral of the story - in future, watch 'The Simpsons' in the kitchen.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Feb 21 '07 #38

P: n/a
tp******@googlemail.com wrote:
On Feb 21, 8:33 am, Keith Thompson <k...@mib.orgwrote:
>websn...@gmail.com writes:
>>Do you truly have no neurons functioning

[snip]

That's about where I stopped reading. If you can't be civil, I'm
just not interested in what you have to say. It's too bad; there
might have been some interesting technical points in there, but I
have better things to do than wade through your crap.

There was an interesting technical point, and I'd be quite
interested to hear you and others talk about it, so I'll reproduce
websnarf's post with the gratuitous insults removed:
>A pointer *ITSELF* is storage, which can be modified. By losing
track of this pointer value, logic errors can easily cause you to
be pointing at the wrong thing when you derefence that pointer.
This is the source of danger. An array is actually implicitely
determined at runtime as a nonmutable pointer that is never NULL
-- if its auto, then its usually just an offset relative to a
stack register. The value cannot be modified at all, and its
storage lifetime is never in question or at issue.

Is an array really equivalent to a non-mutable non-NULL pointer?
Yes, except that that pointer is a different beast than the kind
you normally bandy about and pass hither and yon. It includes such
information as the size and type of the array, the scope, the
location, and what that location is relative to (local or global
storage, which local storage, etc.) (using the common usage for
global/local). It typically lives in the compilers internal
tables.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
Feb 21 '07 #39

P: n/a
we******@gmail.com wrote:
On Feb 20, 3:27 pm, Eric Sosman <esos...@acm-dot-org.invalidwrote:
>Jorge Peixoto de Morais Neto wrote:
>>I was reading the code of FFmpeg and it seems that they use malloc
just too much. The problems and dangers of malloc are widely known.
Isn't it a shame the way people just sit on valuable
information others could benefit from? In the thirty years
I've used C, nobody -- NOBODY -- has warned me about the
"widely known" problems and dangers of malloc(). Well, you
learn something new every day.

You, of course, have never heard of viruses, heap overflows, double
freeing, memory leaking or information leaking. Probably because
these things don't appear in the standard and you haven't looked at
the wider world of computing since the 1970s.
I've heard of all these things, have experienced some of
them, and do not see how they are due to malloc().

On the matter of looking at the wider world of computing,
though, you're right. I looked, I saw websnarf, and I looked
away. Who could blame me?

--
Eric Sosman
es*****@acm-dot-org.invalid
Feb 21 '07 #40

P: n/a
Jorge Peixoto de Morais Neto wrote:
[...]
When I told that "If there is no memory, just let it crash" I was
think of applications like video encoding. If, at the beginning of the
encoding, a buffer cannot be allocated, the program should just exit,
and I don't care about cleanup (since we have no useful data to be
flushed). But of course, I wouldn't do this in the main encoding loop,
since there may be useful data to be flushed, so I should call exit.
Heck, it may happen that he program runs out of memory in the very
last frame of the video...
<off-topic level="mostly">

Something of a reach, but the Marx Brothers addressed this
issue in a scene from "A Night at the Opera." For some reason
Chico and Harpo are pretending to be early aviators who have
flown the Atlantic and are now receiving a heroes' welcome in
America. Chico takes the microphone to describe their exploit
(paraphrase, from memory):

First time we fly to America, we get halfway across, we
run outta gas. So we gotta go back. Second time we
take plennya gas, we get almost all the way across, and
whaddya know? We run outta gas. So we gotta go back.
Third time, we take-a the boat.

</off-topic>
>> exit(ENOMEM); // exit ou abort?
Seems a poor choice of exit status (only 0, EXIT_SUCCESS,
and EXIT_FAILURE are standardized; ENOMEM looks like an `errno'
value, not like an exit status).
Forgive my ignorance, but so what i
Something seems to have been lost -- is this where you ran
outta gas?

After the failure (assuming you choose to exit the program),
there are two likely candidates for the argument to exit(): either
EXIT_FAILURE, which means "failure (of some sort)" on all systems,
or some system-specific failure code that provides more information
("failed in such-and-such a way" rather than just "failed"). There
does not seem to be any standardization of what these other failure
codes might mean, or even whether they're available: You've got
everything from VMS' highly-structured system of condition codes
to Unix' "zero is good, all else is bad."

The program's exit status should not be confused with the errno
value from any particular operation. It is tempting to think of
errno as the "exit status" of a library call, but the analogy is
not good enough. For one thing, errno always has a value but that
value is only meaningful if a function has actually failed. The
program's exit status, on the other hand, always has its meaning
(however that meaning is interpreted by the host system).

By the way, only a subset of library functions are actually
required to set errno when they fail; others may do so (and often
do), but practice varies from implementation to implementation.
The Standard does not require malloc() to set errno; some versions
do and some don't, and some set it "sometimes." There are people
who argue that this means you shouldn't call perror() after failure
in malloc() or fopen() or any other function that isn't guaranteed
to set errno, because you risk printing a meaningless and possibly
misleading error: "Not a typewriter" for an out-of-memory condition,
for example. I belong to what might be called the optimistic camp:
I'm willing to take the risk of emitting a garbage message in the
hope that sometimes the message may be helpful. Take your pick.

--
Eric Sosman
es*****@acm-dot-org.invalid
Feb 21 '07 #41

P: n/a
On Feb 21, 5:15 am, Eric Sosman <esos...@acm-dot-org.invalidwrote:
websn...@gmail.com wrote:
On Feb 20, 3:27 pm, Eric Sosman <esos...@acm-dot-org.invalidwrote:
Jorge Peixoto de Morais Neto wrote:
I was reading the code of FFmpeg and it seems that they use malloc
just too much. The problems and dangers of malloc are widely known.
Isn't it a shame the way people just sit on valuable
information others could benefit from? In the thirty years
I've used C, nobody -- NOBODY -- has warned me about the
"widely known" problems and dangers of malloc(). Well, you
learn something new every day.
You, of course, have never heard of viruses, heap overflows, double
freeing, memory leaking or information leaking. Probably because
these things don't appear in the standard and you haven't looked at
the wider world of computing since the 1970s.

I've heard of all these things, have experienced some of
them, and do not see how they are due to malloc().
Ok, so you see how the OP wrote "The problems and dangers"? See, he's
referring to the same things I am. And some people in the world
actually measure for those kinds of risk, and don't really give a rats
ass about *YOUR* personal experience on the matter. See how that
works? When you talk about things that have been objectively measured
and observed, you are able to assume them with rational people and
have rational discourse about the real issues at hand rather than
having to reiterate the obvious. Objective reality, and things that
are measured inform some people about one way of looking at the world,
while your experience informs *YOU* in an entirely different kind of
way. Your way works for discourse with people who are your fans or
something of that nature, while the objective way is more suited for
this special class of people called "rational" who I don't have to
have ever met before (or even agree with, on very much) to be able to
converse with. Of course I do give up the opportunity to talk to the
"irrationalists", but I guess that's just the price I have to pay.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Feb 21 '07 #42

P: n/a
On Wed, 2007-02-21 at 07:09 -0800, we******@gmail.com wrote:
On Feb 21, 5:15 am, Eric Sosman <esos...@acm-dot-org.invalidwrote:
websn...@gmail.com wrote:
On Feb 20, 3:27 pm, Eric Sosman <esos...@acm-dot-org.invalidwrote:
>Jorge Peixoto de Morais Neto wrote:
>>I was reading the code of FFmpeg and it seems that they use malloc
>>just too much. The problems and dangers of malloc are widely known.
> Isn't it a shame the way people just sit on valuable
>information others could benefit from? In the thirty years
>I've used C, nobody -- NOBODY -- has warned me about the
>"widely known" problems and dangers of malloc(). Well, you
>learn something new every day.
You, of course, have never heard of viruses, heap overflows, double
freeing, memory leaking or information leaking. Probably because
these things don't appear in the standard and you haven't looked at
the wider world of computing since the 1970s.
I've heard of all these things, have experienced some of
them, and do not see how they are due to malloc().

Ok, so you see how the OP wrote "The problems and dangers"? See, he's
referring to the same things I am. And some people in the world
actually measure for those kinds of risk, and don't really give a rats
ass about *YOUR* personal experience on the matter. See how that
works? When you talk about things that have been objectively measured
and observed, you are able to assume them with rational people and
have rational discourse about the real issues at hand rather than
having to reiterate the obvious. Objective reality, and things that
are measured inform some people about one way of looking at the world,
while your experience informs *YOU* in an entirely different kind of
way. Your way works for discourse with people who are your fans or
something of that nature, while the objective way is more suited for
this special class of people called "rational" who I don't have to
have ever met before (or even agree with, on very much) to be able to
converse with. Of course I do give up the opportunity to talk to the
"irrationalists", but I guess that's just the price I have to pay.
http://www.linux-watch.com/news/NS5656359853.html

"As of 2006, at least 20 percent of all in-house business programs were
still being written in Basic."

(And it goes on to say that most of these Basic programmers can't do
anything outside of Basic.)

*** Stupid programmers are the cause of far more problems than poorly
designed languages are. C is not difficult to use safely. The problem is
when non-C programmers try to use it without having learnt how to
program properly. ***

Therefore, /more/ C, at least in our schools, would help code quality
more than /less/ C would.

--
Andrew Poelstra <http://www.wpsoftware.net>
For email, use 'apoelstra' at the above site.
"You're only smart on the outside." -anon.

Feb 21 '07 #43

P: n/a
Andrew Poelstra wrote:
On Wed, 2007-02-21 at 07:09 -0800, we******@gmail.com wrote:
On Feb 21, 5:15 am, Eric Sosman <esos...@acm-dot-org.invalidwrote:
websn...@gmail.com wrote:
<snip>
You, of course, have never heard of viruses, heap overflows, double
freeing, memory leaking or information leaking. Probably because
these things don't appear in the standard and you haven't looked at
the wider world of computing since the 1970s.
>
I've heard of all these things, have experienced some of
them, and do not see how they are due to malloc().
Ok, so you see how the OP wrote "The problems and dangers"? See, he's
referring to the same things I am.
<snip>
[ ... ] Your way works for discourse with people who are your fans or
something of that nature, while the objective way is more suited for
this special class of people called "rational" who I don't have to
have ever met before (or even agree with, on very much) to be able to
converse with. Of course I do give up the opportunity to talk to the
"irrationalists", but I guess that's just the price I have to pay.

http://www.linux-watch.com/news/NS5656359853.html

"As of 2006, at least 20 percent of all in-house business programs were
still being written in Basic."

(And it goes on to say that most of these Basic programmers can't do
anything outside of Basic.)

*** Stupid programmers are the cause of far more problems than poorly
designed languages are. C is not difficult to use safely. The problem is
when non-C programmers try to use it without having learnt how to
program properly. ***

Therefore, /more/ C, at least in our schools, would help code quality
more than /less/ C would.
IMHO, introducing C as the second programming language is good. Since
C doesn't automise many things that some of the other languages do, it
provides an excellent opportunity to learn careful programming.

Feb 21 '07 #44

P: n/a
Jorge Peixoto de Morais Neto wrote:
People also kept arguing that malloc tells you when
>there is not enough memory (by returning NULL) and allows you to do
>something. I don't care much about it, since in the vast majority of
>cases I just close the program when malloc fails.
Would you like the people writing the code for you car's antilock
brakes to follow that approach?

Good example. It reminds that a wrapper like mine should not be
blindly used. I still think it is OK to use in a lot of circustances,
though, as long as you know what you are doing.
the people who wrote the code for my car's anti-lock brakes
used malloc()?!!

<snip>

--
Nick Keighley

"High Integrity Software: The SPARK Approach to Safety and Security"
Customers interested in this title may also be interested in:
"Windows XP Home"
(Amazon)

Feb 21 '07 #45

P: n/a
On 21 fev, 10:47, Eric Sosman <esos...@acm-dot-org.invalidwrote:
After the failure (assuming you choose to exit the program),
there are two likely candidates for the argument to exit(): either
EXIT_FAILURE, which means "failure (of some sort)" on all systems,
or some system-specific failure code that provides more information
("failed in such-and-such a way" rather than just "failed"). There
does not seem to be any standardization of what these other failure
codes might mean, or even whether they're available: You've got
everything from VMS' highly-structured system of condition codes
to Unix' "zero is good, all else is bad."
There is sysexits.h (an attempt of standardization) , although by
reading it I don't know which error should I use. Maybe EX_OSERR, but
I'm not sure.
>
The program's exit status should not be confused with the errno
value from any particular operation. It is tempting to think of
errno as the "exit status" of a library call, but the analogy is
not good enough. For one thing, errno always has a value but that
value is only meaningful if a function has actually failed. The
program's exit status, on the other hand, always has its meaning
(however that meaning is interpreted by the host system).

By the way, only a subset of library functions are actually
required to set errno when they fail; others may do so (and often
do), but practice varies from implementation to implementation.
The Standard does not require malloc() to set errno; some versions
do and some don't, and some set it "sometimes." There are people
who argue that this means you shouldn't call perror() after failure
in malloc() or fopen() or any other function that isn't guaranteed
to set errno, because you risk printing a meaningless and possibly
misleading error: "Not a typewriter" for an out-of-memory condition,
for example.
Funny!
I belong to what might be called the optimistic camp:
I'm willing to take the risk of emitting a garbage message in the
hope that sometimes the message may be helpful. Take your pick.
Well, Unix98 requires malloc to set errno to ENOMEM (from the malloc
man page), and that's good enough to me, in my particular situation.
>
--
Eric Sosman
esos...@acm-dot-org.invalid

Feb 21 '07 #46

P: n/a
Jorge Peixoto de Morais Neto wrote:
People also kept arguing that malloc tells you when
there is not enough memory (by returning NULL) and allows you to do
something. I don't care much about it, since in the vast majority of
cases I just close the program when malloc fails.
Roberto Waltman wrote:
Would you like the people writing the code for you car's antilock
brakes to follow that approach?
Jorge Peixoto de Morais Neto wrote:
>Good example. It reminds that a wrapper like mine should not be
blindly used. I still think it is OK to use in a lot of circustances,
though, as long as you know what you are doing.
"Nick Keighley" wrote:
>the people who wrote the code for my car's anti-lock brakes
used malloc()?!!
Hopefully not! My comment was with regards to "... I just close the
program ...", not to the actual usage of malloc().

But just to be safe, next time you go for an oil change, ask you
mechanic to check the malloc()'s on any on-board computer.
And mail 'the people' a copy of the MISRA standard ... ;)

Roberto Waltman

[ Please reply to the group,
return address is invalid ]
Feb 21 '07 #47

P: n/a
CBFalconer <cb********@yahoo.comwrites:
tp******@googlemail.com wrote:
[...]
>Is an array really equivalent to a non-mutable non-NULL pointer?

Yes, except that that pointer is a different beast than the kind
you normally bandy about and pass hither and yon. It includes such
information as the size and type of the array, the scope, the
location, and what that location is relative to (local or global
storage, which local storage, etc.) (using the common usage for
global/local). It typically lives in the compilers internal
tables.
May I assume that by "Yes", you really meant "No"?

Arrays are not pointers. Pointer are not arrays. An array object
declaration implies a pointer *value* -- but so does any object
declaration:

int i;
/* &i is a pointer to the object */

The only thing special about arrays is the implicit array-to-pointer
conversion.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 21 '07 #48

P: n/a
"Jorge Peixoto de Morais Neto" <pl*****************@gmail.comwrites:
[...]
There is sysexits.h (an attempt of standardization) , although by
reading it I don't know which error should I use. Maybe EX_OSERR, but
I'm not sure.
[...]

sysexits.h is system-specific. I see it on Solaris and Linux, so it
may be common to Unix-like systems, but it doesn't seem to be
mentioned by POSIX.

Furthermore, it doesn't appear to be an attempt to standardize exit
codes in general. Here's part of a comment from the Solaris version:

* SYSEXITS.H -- Exit status codes employed by the mail subsystem.
*
* This include file attempts to categorize possible error
* exit statuses for mail subsystem.
*
* Error numbers begin at EX__BASE to reduce the possibility of
* clashing with other exit statuses that random programs may
* already return.

EX__BASE is 64; few Unix programs that I've seen use exit codes that
large.

0, EXIT_SUCCESS, and EXIT_FAILURE are the only guaranteed portable
exit codes.

<OT>
Common practice on Unix is to use 0 for success, 1 for general error,
and possibly other small integers for specific failure modes
documented for each command.
</OT>

I've seen code that passes errno values to exit(), but it's not common
practice on any systems I'm aware of. In a more strongly-typed
language, errno and the parameter to exit() would likely have
incompatible types.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 21 '07 #49

P: n/a
On 21 fev, 15:58, Keith Thompson <k...@mib.orgwrote:
"Jorge Peixoto de Morais Neto" <please.no.spam.h...@gmail.comwrites:
[...]There is sysexits.h (an attempt of standardization) , although by
reading it I don't know which error should I use. Maybe EX_OSERR, but
I'm not sure.

[...]

sysexits.h is system-specific. I see it on Solaris and Linux, so it
may be common to Unix-like systems, but it doesn't seem to be
mentioned by POSIX.

Furthermore, it doesn't appear to be an attempt to standardize exit
codes in general. Here's part of a comment from the Solaris version:

* SYSEXITS.H -- Exit status codes employed by the mail subsystem.
*
* This include file attempts to categorize possible error
* exit statuses for mail subsystem.
I read somewhere that sysexits was an attempt of general
standardization.
My version says
"This include file attempts to categorize possible error
* exit statuses for system programs, notably delivermail
* and the Berkeley network."

Anyway, programs are supposed to come up with an arbitrary choice for
exit status, whith the recommendation that it is a small integer
(AFAIK). So I arbitrarily choose 12 (the value of ENOMEM on my
system). But it is better to use exit(MYENOMEM), with MYENOMEM defined
to 12, and document it, than to use exit(ENOMEM), because we don't
want the return value of the program to change from system to system.

*
* Error numbers begin at EX__BASE to reduce the possibility of
* clashing with other exit statuses that random programs may
* already return.

EX__BASE is 64; few Unix programs that I've seen use exit codes that
large.

0, EXIT_SUCCESS, and EXIT_FAILURE are the only guaranteed portable
exit codes.

<OT>
Common practice on Unix is to use 0 for success, 1 for general error,
and possibly other small integers for specific failure modes
documented for each command.
</OT>

I've seen code that passes errno values to exit(), but it's not common
practice on any systems I'm aware of. In a more strongly-typed
language, errno and the parameter to exit() would likely have
incompatible types.

--
Keith Thompson (The_Other_Keith) k...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Feb 21 '07 #50

58 Replies

This discussion thread is closed

Replies have been disabled for this discussion.