Porting to RISC OS

[Matthias Andree]

Stefan Bellon <sbellon at sbellon.de> writes:

>> Can you give details? I fail to see how even the most severe malloc()
>> bug would require a rewrite/change of xmalloc.
>
> If malloc(0) causes problems (yes, that would be a bug in malloc), then
> my version doesn't even call malloc(0) in the first place and therefore
> does not run into the trouble whereas the current CVS version first
> calls malloc(0) and then tries to cope with that.

Correct. malloc(0) is rather uncommon; cleaning up when this uncommon
code failed is fine.

> Granted, if malloc is implemented correctly and has no bug, then it
> should work with the current CVS version.

If malloc has bugs, xmalloc cannot fix them, so we'll assume that malloc
works. malloc(0) == NULL is not a bug, but one of the alternatives that
SUSv3 allows for.

xmalloc only makes sure that it doesn't ever return NULL no matter what,
so as to move the "OOM" check out of the main code.

The current implementation is written so that the common code path
(malloc(N), N > 0, returning non-NULL) is fast.

Avoiding malloc(0) a priori means adding a check into the regular
execution path that is unnecessary on some systems and is used very
seldomly on others.

We could even disable the "if NULL and size 0, try malloc(1) as well"
check at ./configure time if a) I cared and b) the autoconf "rpl_malloc"
wrapper wasn't so hideous.

The current xmalloc() code has been tested on those AIX versions that
fall into the "malloc(0) returns NULL" category, so there is no reason
to shuffle that code around again. It's proven, there is no bug to be
fixed, so touching it would be wrong.

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95