RE: Agree: Require ANSI C for development [Was: libwww ]
Subject: RE: Agree: Require ANSI C for development [Was: libwww ]
Date: Wed, 13 Jul 1994 22:00:28 +0200
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.
- 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
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 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.