Re: calloc/free: a preplexing observation

From: Chris Croughton (chris_at_keristor.net)
Date: 02/04/05 

Date: Thu, 3 Feb 2005 23:52:11 +0000

On Thu, 03 Feb 2005 22:30:01 GMT, Keith Thompson
   <kst-u@mib.org> wrote:

> I contend that the following program is strictly conforming (assuming
> that any program that writes to stdout can be strictly conforming):
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main(void)
> {
> char *ptr = malloc(0);
> printf("Hello, world\n");
> return 0;
> }
>
> If it doesn't print "Hello, world" when I execute it, that's a bug in
> the implementation. You seem to be arguing that if any statements
> that follow malloc(0) are *never* executed, that's acceptable. (If it
> happens to fail because somebody pulled the power plug before it was
> able to finish, that's a different story.)

Define 'acceptable'. It could be failing for a number of reasons and
still be compliant with the standard (as far as I can see it is only
guaranteed that a C program exists and works which has a data block of
up to 64K-1 bytes, but it might be required that this block is
statically allocated).

> But in this case, it's not only possible, it's easy. Regardless of
> whether lazy allocation is conforming or not, an implementer who wants
> to provide a non-lazy malloc() can do so.
>
> The requirement for malloc() is that it has to behave as the standard
> requires, not as some OS routine happens to behave.

But there is nothing to say that events outside its control might not
stop it from working.

> Sure, a program can die at any time due to external influences
> (somebody kills the process, the OS runs out of resources, somebody
> pulls the power plug).

Or ir unexpectedly runs out of memory (perhaps someone did "swapoff" in
the middle of execution, or the OS did it automatically).

> And it's very difficult to define when this
> constitutes a violation of the C standard and when it's just a case of
> "oh well, stuff happens". If my program dies when my infinitely
> recursive function call attempts to allocate a terabyte of memory, I
> have no grounds for complaint. If it dies whenever I try to compute
> 2+2 in a strictly conforming program, that's a bug in the
> implementation.

Only if you include the hardware in the implementation as well.

> If it dies when I try to access memory that was
> allocated by an apparently successful malloc() call, I'm going to be
> grumpy.

Quite possibly, but that's a QoI issue not a standard compliance one.

> What I am guaranteed is that if malloc() returns a non-null result,
> the memory I requested was allocated. The question is what
> "allocated" means.

Ecaxtly.

> There's also the issue of which behavior is more useful (which is
> separate from the question of what the standard actually requires).
> If C programs commonly use malloc() to allocate huge amounts of
> memory, and then only use part of it, overallocation makes sense. If,
> on the other hand, a program malloc()s a block of memory only if it's
> actually going to use all of it, overallocation merely causes certain
> errors to be detected later and without any recourse. If I request a
> megabyte of memory that the system can't or won't give me, I'd rather
> have the malloc() fail cleanly than have my program abort later on.

How about (as is far more likely) it just waits until memory is
available? The standard says nothing about performance, if the OS is
swapping "unused" memory to mag tape and prompts the operator to load
the other mag tape, and they don't get round to it for a couple of days,
you may well get pissed off but it isn't against the standard. Or if
they decide "your program is using too much memory so I'll kill it" (or
if the OS decides the same) it isn't a violation of the standard, it's
just a QoI issue.

> I would think that it's rare for C programs to malloc() memory that
> they're not actually going to use, and I would argue that programs
> that do so are misbehaving.

I would argue that it is common and that they are not misbehaving at
all. Any program allocating large arrays (where 'large' means more than
a few KB) as uninitialised variabled will probably not have that data in
"real" memory (RAM or swap) until the program writes to it on most Unix
systems. The same may even be true of large arrays on the stack on some
systems. It's not something whicvh is unique to malloc and dynamic
memory allocation.

If you don't like the QoI, you are free to use another system, or turn
off the 'lazy' memory allocation if you have that privilege, but it is
still standard conformming.

Chris C

Relevant Pages

  • Re: A solution for the allocation failures problem
    ... Can you find anything in the standard which *allows* this behaviour? ... it defines how your C program is supposed to behave. ... previously allocated memory available for further allocation. ... says the memory will be made available for further allocation. ...
    (comp.lang.c)
  • Re: Freeing memory - will it be available immediately
    ... Your interpretation of "as the standard defines it" is ... Your interpretation of "for further allocation" as "for futher ... Except that this ignores the very reason for the standard, ... return the memory back to the OS in the manner you describe. ...
    (comp.lang.c)
  • Re: malloc under linux
    ... It means what it says, i.e., even if malloc returns a non-null ... memory might not actually be allocated. ... Standard even when some other process is killed and sufficient memory is ... I can't see how the Standard does not permit lazy allocation, ...
    (comp.lang.c)
  • Re: Freeing memory - will it be available immediately
    ... Earlier you did seem to stress the fact that the standard does nothing ... further allocation" as returning the memory to the place it came from. ... word "allocate" can be taken to be a change of ownership. ...
    (comp.lang.c)
  • Re: Variable length arrays
    ... standard text, but couldn't find a definite answer there either. ... a strictly conforming program can't tell whether the ... program most certainly does generate output that shows the same memory ...
    (comp.lang.c)