Re: proposal: scm_string2str() and scm_symbol2str()

[stefan]

On Mon, 20 Nov 1995, Dirk Herrmann wrote:

> On Mon, 19 Nov 2001, stefan wrote:
> 
> > > >  * To have sane memory allocation interface between C and libguile
> > > >    put scm_c_free(), scm_c_malloc() and scm_c_realloc() into `gc.[ch]'.
> > > 
> > > What would these functions do?
> > 
> > /* Memory allocation functions: Used within the `SCM -> C array type' 
> >    conversion functions.  These should be used instead of the standard
> >    malloc(), free() and realloc() functions provided by any underlying
> >    libc implementation.  It avoids problems with applications using a
> >    installed Guile library (libguile) and which use a different libc 
> >    implementation.  */
> > 
> > Thus these functions are very simple wrappers for free(), malloc() and
> > realloc().
> 
> Sorry, I don't get it.  If guile allocates the memory using malloc, then
> it would use the libc implementation of malloc, wouldn't it?  How could
> there be a conflict if the user used free on that memory?

I must admit that I've never seen this on a Unix platform.  But
unfortunately it is common use on M$-Windows platforms to replace a
written "free()" to different kinds of heap allocation free()'s depending
on the "memory model".  Is this reason enough to have such functions?

Yet another pointer might be c++.  If you use Guile inside c++ code you
could define a class::free()...  This a reason?

Cheers,
        address@hidden