malloc and realloc

[matevzb]

So there's a memory leak for some tiny number of clock cycles until abort()
is called... big deal.

Well yes, if you want to abort() I suppose that's okay.

"E.g." means "for example". As you admit, this example already has uses -
in many small single-purpose programs it simply doesn't make sense to
carry on if you can't allocate memory.
With a little initiative you can modify the macro... e.g. have a global variable
to store the original pointer, and replace abort() by some cleanup
code.

Personal opinion: I'd rather not do it in a macro, especially one with
the same name as a C library function - it's obfuscation.

If you do it right, you'll be able to transparently handle allocation
failures in-place too, on the few occasions when that's really beneficial.

Another personal opinion: The "few occasions" may not be so few when
dealing with e.g. large databases or daemons.

That's personal opinion. Consistency and clear documentation are what
make code easier to debug. I personally find source files with hundreds
of if-clauses for (m|re)alloc failure scattered everywhere far harder
to read.

It's quite easy to be consistent when writing code all by yourself. If
not, I'd rather take every precaution necessary, rather than rely on
consistency and clear documentation. People are sometimes forgetful,
sloppy, unaware or just plain lazy, so I rely on the code instead.
This is also a personal opinion, derived from experience.

 

[tphipps]

At the risk of repeating myself...

Terrible idea. Illegal to start with (#defining system routines)
although it will usually work. However normally you don't want to
abandon everything whenreallocfails, since all your data is still
intact. A better idea is:

*snip something identical to what I first commented on*

"E.g." means "for example". This example already has uses - in many
small single-purpose programs it simply doesn't make sense to carry on
if you can't allocate memory.

With a little initiative you can soup up the macro... e.g. have a
global variable to store the original pointer temporarily, and replace
abort() by some cleanup code. If you do it right, you'll be able to
transparently handle allocation failures in-place too in the "usual"
way on the few occasions when that's really beneficial.

Any time you see "x =realloc(x, size);" you have a potential
memory leak, and you know the coder is probably inexperienced.
Exceptions exist.

So there's a memory leak for some tiny number of clock cycles until
abort() is called... big deal.

 

[santosh]

Well yes, if you want to abort() I suppose that's okay.

As far as I can tell, abort() is unacceptable for production code.
IIRC, in the US, it's even illegal for a program to terminate by
calling abort().

 

[santosh]

At the risk of repeating myself...

On Jan 28, 4:20 pm, CBFalconer <[email protected]> wrote:

So there's a memory leak for some tiny number of clock cycles until
abort() is called... big deal.

Some primitive systems are unable to reclaim memory lost through a
program leak. DOS and Windows 3.x series were famous for this feature.
IIRC, even Windows 95 occasionally suffered from this deficiency.

 

[tphipps]

program leak. DOS and Windows 3.x series were famous for this feature.
IIRC, even Windows 95 occasionally suffered from this deficiency.

ROFLMAO. It wouldn't surprise me!

 

[Keith Thompson]

As far as I can tell, abort() is unacceptable for production code.
IIRC, in the US, it's even illegal for a program to terminate by
calling abort().

Um, no.

 

[Ben Pfaff]

As far as I can tell, abort() is unacceptable for production code.
IIRC, in the US, it's even illegal for a program to terminate by
calling abort().

You are taking a distasteful joke in the GNU libc manual far too
seriously.

 

[Richard Tobin]

Some primitive systems are unable to reclaim memory lost through a
program leak. DOS and Windows 3.x series were famous for this feature.
IIRC, even Windows 95 occasionally suffered from this deficiency.

It's best not to write programs that pander to such operating systems.

-- Richard

 

[CBFalconer]

It's best not to write programs that pander to such operating systems.

It's best not to write programs with unnecessary built-in problems.

 

[Keith Thompson]

It's best not to write programs that pander to such operating systems.

Unless you have to. Some people have to.

 

[Yevgen Muntyan]

Some primitive systems are unable to reclaim memory lost through a
program leak. DOS and Windows 3.x series were famous for this feature.
IIRC, even Windows 95 occasionally suffered from this deficiency.

In those cases abort() call is the problem, not that single leak,
since all memory allocated elsewhere isn't freed, right? Should
a program never call abort() ? How about exit(EXIT_FAILURE) and such?
Anyway, it was about "memory leak for some tiny number of clock cycles"
which indeed is that - a "leak" that nobody can even notice.

Yevgen

 

[santosh]

In those cases abort() call is the problem, not that single leak,
since all memory allocated elsewhere isn't freed, right?

Yes. That's why it's good practise to release resources after you've
used it.

Should a program never call abort() ?

It's fine during development and debugging, but during actual use, in
most cases, you can shut down far more gracefully than abort()ing.

How about exit(EXIT_FAILURE) and such?

Better, but still, the fact remains that he hasn't explicitly
free()'ed the memory he allocated, thus setting up a potential memory
leak.

Anyway, it was about "memory leak for some tiny number of clock cycles"
which indeed is that - a "leak" that nobody can even notice.

Except on the above mentioned systems.

 

[Richard Heathfield]

(e-mail address removed) said:

If you are always going to be that cautious,

That's not a matter of caution. It's just simple common sense. You don't
throw away resources you've carefully acquired until you're sure you don't
need them any more.

why not save typing by wrapping it in a macro, e.g.

#include <stdlib.h>
#define realloc(x,y) ( (x=realloc(x,y)) ? x : ( abort(), NULL ) )

Because I don't consider failure to be an option, and I don't consider
"saving typing" to be a good reason for throwing away your chance to detect
and *deal with* a low memory condition. That's the "student solution" - not
because it's such good practice that they even make students do it, but
because it's such bad practice that only students can get away with it.

 

[Richard Bos]

Actually Windows guarantees that allocations of under 8K or something like
that will succeed, unless

Precisely. _Unless_. And it's _your_ duty that your user doesn't get
bitten by the "unless".

So on a modern operating system you don't need to check small mallocs.

On _one_ modern operating system, _if_ you like gambling with your
users' data, you don't need to check small malloc()s. In other
situations: Do The Right Thing.

Richard

 

[Richard Tobin]

It's best not to write programs that pander to such operating systems.

[/QUOTE]

Unless you have to. Some people have to.

Yes, of course. And in embedded systems there may be justifications
for such a situation. But fortunately I - and many people - don't
have to. I prefer to encourage good general-purpose operating systems
and I'm not going to go out of my way to compensate for the failings
of operating systems that I'd rather fell into well-deserved
obsolescence.

-- Richard

 

[Malcolm McLean]

On _one_ modern operating system, _if_ you like gambling with your
users' data, you don't need to check small malloc()s. In other
situations: Do The Right Thing.

How is writjng code that can never be executed going to defend your user
from the system going into panic mode due to lack of memory?

 

[Flash Gordon]

Malcolm McLean wrote, On 30/01/07 07:48:

How is writjng code that can never be executed going to defend your user
from the system going into panic mode due to lack of memory?

When on Vista SP1 things are changed so that it is executed. Or when it
is ported to some other system where it is executed.

By the way, I consider exiting the application with an appropriate error
message entirely appropriate for one major application I work on. This
is because the application runs on dedicated servers and has a small
memory footprint so in the 6 years I've been with the company malloc has
only failed when there has been a bug in the code serious enough that
the application would not have been able to recover anyway (it was in an
infinite loop allocating more and more memory).

From our customers perspective they would rather we spend the time
writing the other features they want than to write recovery code.
However, the application crashing *without* us detecting the event and
producing an appropriate error would upset them a lot.

 

[Eric Sosman]

Malcolm McLean wrote On 01/27/07 15:16,:

Actually Windows guarantees that allocations of under 8K or something like
that will succeed, unless the program is responding to a request to shut
down due to lack of memory, in which case 64K of allocation or so is
guaranteed, but not an infinite supply of 64K chunks.

I have no knowledge of the supposed "guarantee," but it's
obviously been mis-stated here: Even a small allocation can
fail. For example, try running

#include <stdlib.h>
#include <string.h>
int main(void) {
while (1)
strcpy(malloc(14), "Hello, world!");
}

So on a modern operating system you don't need to check small mallocs.

Nonsense. A large number of small allocations will
eventually consume all of a finite resource.

You
do if code is to be completley portable, of course.

Or if you want code that isn't "completley" unreliable.