[dev-serveez] memory management

[stefan]

Dear Guile'ers,

the manual from HEAD branch CVS tells me to use scm_malloc() instead of
scm_must_malloc() when allocating memory not connected to smobs.  There is
no scm_free():

 > The memory is allocated by the libc @code{malloc} function and can be
 > freed with @code{free}.  There is no @code{scm_free} function to go
 > with @code{scm_malloc} to make it easier to pass memory back and forth
 > between different modules.

Can you plese explain what "make it easier to pass memory back and forth
between different modules" means?  What are modules in this context?

Wouldn't it be more othogonal to supply a scm_free()?

The actual reason I ask for the implementation of a scm_free() is as
follows.  I am a developer of Serveez.  It uses Guile as configuration
language and also as implementation language for quite some time.  The
software is portable to Win32.  Thus we need Guile be portable to Win32.
Lots of the changes in Guile CVS regarding Win32 portability were made by
myself.  On Win32 systems there is not such a thing like a standard libc.
There are different APIs around, especially regarding memory management.
When you use e.g. gh_scm2newstr() from an application linked against
libguile.dll (which was ported using the msvcrt.dll - one of the libc's)
and the calling application is linked against another libc (e.g.
kernel32.dll only) which provides 'another' free() as the msvcrt.dll... it
fails!  This is bad I know, but not to work around...

Would you supply a scm_free() inside libguile.dll there would be no
problem, because then the free() called inside libguile.dll:scm_free()
would match the previous malloc() (also called inside libguile.dll).

In previous versions of Guile I helped myself calling scm_must_free()
which sufficed for this purpose perfectly.

Thanks in advance,
        address@hidden

PS: Please CC answers to my private email, because I wouldn't read the
    guile-devel list too regularily.

PPS: I am waiting for the coop-thread thingie to have finsished in Guile
     devel to put the pending changes regarding Win32 portability into
     CVS...