- From: <hallam@alws.cern.ch>
- 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. 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. Phill
Received on Wednesday, 13 July 1994 22:00:11 UTC