RE: Agree: Require ANSI C for development [Was: libwww ]

It's not a question of keeping things simple, you can do an awfull
lot more if you know the type of the thing you are mallocing. 

For example 

- intelligent memory allocation/ release, reusing old blocks from a heap.
- interface to data model with automatic initialisation
- use metadata to automatically free all dependent structures,
	do pretty printing etc.

AND you can also automate the cast!

#define W3_MALLOC(type,number) (type *) malloc (sizeof(type) * number)

So in code you get:-

new = W3_MALLOC (char, 1024);
new = (char*) malloc (sizeof(char)*1024);

So you remove the possibility of an error mistyping char. Plus if you have 
a super duper memory allocator you can still use it!

On the status value:-

The problem with returning NULL is that you can't know WHY the malloc 
failed. It may be because there is no memory left at all in the system 
or because a prearranged limit has been reached which could be increased
at user discression - eg if you have a cache system where storing the data
is optional...

Depending on the situation the user may be able to complete the operation by
flushing the cache or there may simply not be enough memory. Compressing
error return codes to binary success/fail values was a very bad idea
in UNIX.

In fact I would like to suggest that we move to a system where EVERY routine
returns a status code value. This could either be a simple integer or a
pointer to a structure (more macros, should be a choice!). This means that
you always know how to expect the status code and not have a mish mash of
different status conventions.