Implementing Malloc()

[Mark McIntyre]

We were discussing implementing malloc(), in particular the following
situation.

Suppose the user requests 1Mb of memory. Unfortunately, we only have
512Kb available. In this situation, most mallocs() would return null.
The huge majority of programmers won't bother to check malloc() failure
for such a small allocation, so the program will crash with a SIGSEGV as
soon as the NULL pointer is dereferenced.

So why not just return a pointer to the 512Kb that's available?

Yike. Take this to the extreme. Imagine you only have one byte
available. Why not just return a pointer to that? How much use is /that/?

It's
quite possible that the user will never actually write into the upper
half of the memory he's allocated,

Its also quite possible the programmer knew how much memory he needed,
and will be justifiably annoyed when his programme starts randomly failing.

 

[Dik T. Winter]

> The idea is that instead of a guaranteed crash, isn't it better to make
> a last-ditch effort to save the program's bacon by returning a pointer
> to what memory there _is_ available? If the program's going to crash
> anyway, it's got to be worth a shot.

In that case there is no way a program can actually *check* whether there
was sufficient memory, which a well written program should do. The result
is probably a fault, but all kind of other nasty things can happen, like
completely wrong output.

 

[J. J. Farrell]

All very amusing, but I think you and some of the other posters have
misunderstood the context of the discussion.

Of course an implementation of malloc should return a pointer to as much
memory as requested whenever that's possible! The discussion was about
the rare failure case. Typically, programs assume malloc returns a
non-null pointer, so if it returns null on failure then the program will
crash and burn.

Why do you think such incompetently written buggy programs are "typical"?

The idea is that instead of a guaranteed crash, isn't it better to make
a last-ditch effort to save the program's bacon by returning a pointer
to what memory there _is_ available? If the program's going to crash
anyway, it's got to be worth a shot.

No, blatantly and obviously not. It is better for the programmer's
incompetence to cause the program to stop execution immediately rather
than allow it to go on with random behaviour doing who knows how much
damage to what. How does, for example, corrupting a few gigabytes of
valuable archive data "save the program's bacon"?

 

[MisterE]

The worst thing that can happen is that the programmer _does_ write to
the end of the mallocated block. In this case, either there's a SIGSEGV
again (no worse off than before), or if the 512Kb is in the middle of
the heap malloc() is drawing from then the writes might well succeed,
and the program can continue albeit with some possible minor data
corruption.

Do any implementations of malloc() use a strategy like this?

omg

this is dumbest thing I have read on the internet

 

[Malcolm McLean]

No, blatantly and obviously not. It is better for the programmer's
incompetence to cause the program to stop execution immediately rather
than allow it to go on with random behaviour doing who knows how much
damage to what. How does, for example, corrupting a few gigabytes of
valuable archive data "save the program's bacon"?

It does depend what the program is. For instance with a videogame there is
no point exiting with an error message. You might as well ignore the error,
and there's a chance the player won't notice. If he does notice, it won't
spoil his enjoyment any more than an exit.
Unless of course you manage to corrupt his saved character which he's spent
two years of solid gameplay bringing up to a high level. Then people get
annoyed.

 

[Keith Thompson]

It does depend what the program is. For instance with a videogame
there is no point exiting with an error message. You might as well
ignore the error, and there's a chance the player won't notice. If he
does notice, it won't spoil his enjoyment any more than an exit.
Unless of course you manage to corrupt his saved character which he's
spent two years of solid gameplay bringing up to a high level. Then
people get annoyed.

Even in that context, the proposed malloc implementation where a
request for 1024 kbytes can allocate just 512 kbytes and not report an
error doesn't seem particularly useful.

And if it is useful, you can always implement it on top of malloc *and
call it something else*.

 

[christian.bau]

It does depend what the program is. For instance with a videogame there is
no point exiting with an error message. You might as well ignore the error,
and there's a chance the player won't notice. If he does notice, it won't
spoil his enjoyment any more than an exit.

I once played "Who wants to be a millionaire" on a Playstation. The
program crashed at the £8,000 question. It would have been more
enjoyable if the program had crashed immediately.