Re: malloc problem/question in 2.1.3

[Kaz Kylheku <kaz at ashi dot footprints dot net>]

On Thu, 1 Jun 2000, Mike Corbeil wrote:

> Date: Thu, 01 Jun 2000 15:06:14 -0400
> From: Mike Corbeil <mcorbeil@netrevolution.com>
> Reply-To: glibc-linux@ricardo.ecn.wfu.edu
> To: glibc-linux@ricardo.ecn.wfu.edu
> Subject: Re: malloc problem/question in 2.1.3
> 
> David Ronis wrote:
> 
> > Please ignore my previous post, I'd been free'ing an unrelated (and unused)
> > block of memory when I shouldn't have been.   I don't understand exactly
> > why this should give a SIGSEGV, but it's fixed.
> >
> 
> As you probably guessed, this is because free doesn't (at least didn't in this
> case) check if the argument is valid or not, that is, if there's actually any
> memory attached to the pointer passed as an argument.  However, why free
> wouldn't check for something like this leaves guess work.

The answer to that is easy: it's for performance reasons. The checks would
be a waste of time in a correct program.

If you need a debugging malloc library, you can get one: ElectricFence,
dmalloc, etc.

> If I'm not mistaken, then I vaguely recall someone saying, numerous years ago,
> that free couldn't check this and that this is why free isn't as reliable or
> friendly as some or many would like.

The free function is an interface specified by ANSI C. The semantics of that
interface are such that if you try to free a pointer that did not originate
from the allocator, the behavior is undefined. Also, any use of an
indeterminate pointer is undefined.  Undefined behavior means that the
implementation is not required to do anything about it, possibly leading
to unpredictable results.

There is no inherent unreliability in the malloc interface. When you misuse
something and it fails, it indicates a lack of robustness, not reliability.
When you use something in accordance with its specification and it fails
anyway, that indicates unreliability.

Robustness can be expensive, therefore in practice it's wortwhile achieving
it only where it is essential, like between the program and the outside world
(guarding against bad inputs) or at major interface boundaries (e.g. process
and kernel).

> As a short aside, I think that this could be checked for in Perl using
> "defined" (e.g., if defined $var ...), however C is a compiled language and I
> don't think there's any such functionality, not afaik anyway.

Checking whether a pointer refers to an existing, allocated object could
require a potentially expensive search.  For example, the allocator may have to
keep track of all allocated objects in a tree structure, and search this
structure whenever something is freed.  The bounds checking patches for gcc 2.7
did something like this (but for all objects, not just dynamic ones).