This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [ANN]: guilegc r8


> 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?

At least it brings it into line with the realloc from the C library
which is what people will expect when they see something with realloc
in its name.

> however), but this is also a matter of principle.

In principle I agree, less is better. From another point of view,
if you extend the realloc behaviour then that becomes the only
memory function that you ever need -- is this `less' or `more'
regarding program complexity.

> 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.

Useful for C style arrays where you initialise to a null pointer
and then realloc as you change the array size. When you shrink back
to zero size you don't need a special case in your code, just keep
on reallocing.

> 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.

My feeling is that realloc is for when you know how much memory
you are freeing, free() implies that you don't know exactly how
much memory you had (or don't care).

	- Tel