When to check the return value of malloc

[Keith Thompson]

I think you are not seeing the whole picture here. You should think of
alternative situations too.

Maybe you want the allocation to perform a fast sort routine. If you
can't get enough memory, you can just fall back to a slower out-of-core
sorting routine.

I think you didn't bother to read the rest of my article, in which I
specifically acknowledged the same point you just made.

 

[Eric Sosman]

I think you are not seeing the whole picture here. You should think of
alternative situations too.

Maybe you want the allocation to perform a fast sort routine. If you
can't get enough memory, you can just fall back to a slower out-of-core
sorting routine.

What part of "fall back to some other approach" are you
having trouble understanding?

Besides, this whole thread started with your suggestion
that there's no reason to check the value of malloc() for "small"
requests. In the scenario you describe, how could you choose
between algorithms without making the check? I know of one way,
but it's pretty silly:

Type *ptr = malloc(SMALL_SIZE);
free(ptr);
do_slow_sort();

 

[Dann Corbit]

What part of "fall back to some other approach" are you
having trouble understanding?

Besides, this whole thread started with your suggestion
that there's no reason to check the value of malloc() for "small"
requests. In the scenario you describe, how could you choose
between algorithms without making the check? I know of one way,
but it's pretty silly:

Type *ptr = malloc(SMALL_SIZE);
free(ptr);
do_slow_sort();

If a component is to be considered reliable, then the return status of
malloc() must be checked.

Any other assertion is ludicrous.

There are a few functions in the C library where we normally don't need
to analyze the return. An example would be puts(). If puts() fails,
exactly what are we going to do about it?

But for things like fopen(), fwrite(), malloc(), etc. that rely upon
resource availability, user rights, etc. it is sloppy, lazy, and stupid
not to examine the return code.

 

[sandeep]

Besides, this whole thread started with your suggestion
that there's no reason to check the value of malloc() for "small"
requests. In the scenario you describe, how could you choose between
algorithms without making the check? I know of one way, but it's pretty
silly:

Type *ptr = malloc(SMALL_SIZE);
free(ptr);
do_slow_sort();

I'm sorry you want to make this silly instead of a serious discussion.

But anyway you are wrong: if malloc returns a NUL pointer then free may
blow up if it tries to dereference its argument.

 

[Dann Corbit]

I'm sorry you want to make this silly instead of a serious discussion.

But anyway you are wrong: if malloc returns a NUL pointer then free may
blow up if it tries to dereference its argument.

Supposing that you mean a NULL pointer, I suggest you read the ANSI/ISO
C standard. Consider the second sentence of #2 below:

7.20.3.2 The free function
Synopsis
1 #include <stdlib.h>
void free(void *ptr);
Description
2 The free function causes the space pointed to by ptr to be
deallocated, that is, made available for further allocation. If ptr is a
null pointer, no action occurs. Otherwise, if the argument does not
match a pointer earlier returned by the calloc, malloc, or realloc
function, or if the space has been deallocated by a call to free or
realloc, the behavior is undefined.
Returns
3 The free function returns no value.

 

[Seebs]

I'm sorry you want to make this silly instead of a serious discussion.

I think he's pointing out that you already made it silly.

But anyway you are wrong: if malloc returns a NUL pointer then free may
blow up if it tries to dereference its argument.

Incorrect. free(NULL) may not blow up. It's required to work by the
standard, and has been for about twenty years.

-s

 

[Seebs]

What I think this overlooks is:

It overlooks nothing.

THAT IS THE SPECIFICATION OF THE LANGUAGE.

malloc may return a pointer to an area of
memory with some "bookkkeeping info" at the beginning, eg size of block,
pointer to next buddy block. Free will then need to read this info, which
will involve dereferencing the pointer. If the pointer is NULL... bang!

No, free won't need to read that info, because the first thing it would do
is check to see whether the pointer is a null pointer, and if it is, return
without doing anything.

It doesn't matter how easy or hard it is for the implementor to comply.
They are *REQUIRED* to correctly do nothing without crashing if a null
pointer is passed to free(). As it happens, this is very easy.

You have about three posts left to convince me that you're not a troll who's
just trying to stir stuff up by posting hilariously wrong stuff before I plonk
you and stop trying to help you. I've rarely seen someone so militantly
unwilling to learn.

-s

 

[sandeep]

7.20.3.2 The free function
Synopsis
1 #include <stdlib.h>
void free(void *ptr);
Description
2 The free function causes the space pointed to by ptr to be
deallocated, that is, made available for further allocation. If ptr is a
null pointer, no action occurs. Otherwise, if the argument does not
match a pointer earlier returned by the calloc, malloc, or realloc
function, or if the space has been deallocated by a call to free or
realloc, the behavior is undefined.

What I think this overlooks is: malloc may return a pointer to an area of
memory with some "bookkkeeping info" at the beginning, eg size of block,
pointer to next buddy block. Free will then need to read this info, which
will involve dereferencing the pointer. If the pointer is NULL... bang!

 

[Dann Corbit]

What I think this overlooks is: malloc may return a pointer to an area of
memory with some "bookkkeeping info" at the beginning, eg size of block,
pointer to next buddy block. Free will then need to read this info, which
will involve dereferencing the pointer. If the pointer is NULL... bang!

I think you have an interesting imagination. However, when it comes to
programming, it's a good idea to use specifications instead of your
imagination.

IOW, you are dead wrong. If an implementation goes 'bang' because you
freed a NULL pointer, then the implementation is broken and you have the
right to complain to your compiler vendor.

If you are paranoid about broken compilers, you can always test the
return value of malloc() and if it is NULL, don't bother freeing it,
since free() in this instance is simply a no-op.

 

[Tim Streater]

What I think this overlooks is: malloc may return a pointer to an area of
memory with some "bookkkeeping info" at the beginning, eg size of block,
pointer to next buddy block. Free will then need to read this info, which
will involve dereferencing the pointer. If the pointer is NULL... bang!

No, if the pointer is NULL then, no action, like it says. I would have
expected malloc to do its memory management well away from any block
that it returns a pointer to.

 

[Phil Carmody]

Since you're talking about a gcc-specific extension (and since C already
has a ?: operator), perhaps explaining it would have been a good idea.

Nope, my time's too valuable to me currently. Anyone interested enough
in gcc specifics had all the clues available to them in order to stick
them into a search engine.

Phil

 

[Phil Carmody]

Phil Carmody wrote:


I construct objects very often in C. What's the problem?

I don't remember using the word 'problem'. Your use of the
definite article implies that there ought to be a single
unambiguous instance of same. Sounds like a PDtCP moment.

Phil

 

[Eric Sosman]

I'm sorry you want to make this silly instead of a serious discussion.

It's been silly from the get-go. You starte the thread by
proposing to omit checking malloc() values; that's silly to begin
with. Then you suggested using malloc() in hopes of getting enough
memory for a fast algorithm, but falling back on a slow algorithm
if malloc() failed. Put the two ideas together, and the second
highlights the silliness of the first -- I didn't add the silliness,
I just shone a brighter light on silliness already present.

But anyway you are wrong: if malloc returns a NUL pointer then free may
blow up if it tries to dereference its argument.

Do you know *any* C? Open your textbook or reference (if you
own one, which I'm beginning to doubt) and read what it tells you
about the behavior of free(NULL). Go on, do it now -- before you
post still more nonsense.

 

[Phil Carmody]

I'm sorry you want to make this silly instead of a serious discussion.

But anyway you are wrong: if malloc returns a NUL pointer then free may
blow up if it tries to dereference its argument.

Woo woo - we have been trolled.


Phil

 

[Phil Carmody]

From: sandeep <[email protected]>
Organization: Aioe.org NNTP Server

Frig, it was there in black and white all along.

What was the final score?

Phil

 

[Seebs]

Frig, it was there in black and white all along.

It seems likely.

What was the final score?

Hard to say. I do concede that, between this and the various other very
densely packed mistakes (using NUL for "null pointer", etcetera), arguing
with everyone, and most recently, saying that the C standard overlooks
something about real implementations, this has GOT to be a joke. A very
nicely done one, though.

IHBT. IHL. IWHAND.

-s

 

[Keith Thompson]

Nope, my time's too valuable to me currently. Anyone interested enough
in gcc specifics had all the clues available to them in order to stick
them into a search engine.

I happened to have read about about gcc's extension of the
conditional operator previously, so I knew what you were talking
about. Someone who didn't know about it would assume that ?:
referred to the operator defined by the C standard (and would
wonder what you meant by ``gcc's "?:"'' and why you think it should
be standardized).

When some of your valuable time becomes available, try sticking "?:"
into a search engine and see what happens.

 

[Tim Harig]

Frig, it was there in black and white all along.

HEY!!!

 

[Seebs]

I happened to have read about about gcc's extension of the
conditional operator previously, so I knew what you were talking
about. Someone who didn't know about it would assume that ?:
referred to the operator defined by the C standard (and would
wonder what you meant by ``gcc's "?:"'' and why you think it should
be standardized).

I even KNOW about it, and didn't realize that was the intended reference.

Speaking of GNU C: Nested functions, worst idea ever. I have never seen
them used in a remotely sane way. I did, however, just encounter a provably
insane nested function which Made No Sense At All. Also it caused crashes
on the ARM compiler. But mostly it was just insane.

It is the Flying Dutchman of C language extensions, a solution doomed to
wander the libraries and source trees of the world until the end of the time,
seeking a problem.

-s

 

[Seebs]

HEY!!!

The occasional counter-examples don't do much to undermine the general
principle. aioe exists to allow people to harass with impunity.

-s