Re: [ANN]: guilegc r8

[Mikael Djurfeldt <mdj@nada.kth.se>]

Greg Harvey <Greg.Harvey@thezone.net> writes:

> r8 adds the ability to scm_must_malloc/realloc/free to totally
> control the value of scm_mallocated (only possible if using glibc,
> currently), and also adds swiss-army knife functionality to
> scm_must_realloc (suggested by Telford Tendys) (will free the pointer
> if len == 0, and malloc new storage if the pointer is NULL).

Is it really good to add functionality to such low-level routines?
What if I am using scm_must_realloc intensely in some task where
there's no sense in testing for len == 0 and freeing?

Probably the speed penalty of extra tests isn't important compared to
the work done by realloc in this case (there is a complexity penalty,
however), but this is also a matter of principle.

I think we should be very restrictive with adding arbitrary
functionality in low-level routines which are used by the entire
library.  How useful is it that a realloc to zero frees the block?  I
can't remember a single situation where I would have benefited from
that.

And a programming style which uses realloc instead of free is really
bad.  The names of function calls are supposed to give a good picture
of what is happening at that point of a program.  If you use
malloc/free it is obvious what is allocation and what is freeing.  If
you would use realloc/realloc the program becomes obscured.

/mdj