Re: memory management

[Marius Vollmer]

stefan <address@hidden> writes:

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

`Modules' is meant to mean different, errm, 'code regimes', like
libraries from different projects or developers.  These different
bodies of code have not necessarily been specifically written to work
together, but supposedly, they all use libc for their basic memory
management.

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

Yeah, but we would force people to always pair scm_malloc with
scm_free.  (Offering scm_free without forcing people to use it would
have no effect.)  When they can't use scm_free because they have no
control over the code doing the freeing, they consequently can't use
scm_malloc although it might have been the right thing.  By not
insisting on scm_free, we make scm_malloc more useful.

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

This sounds like a very fundamental problem and I frankly don't want
to be drawn into the maelstrom of trying to fix it.  Next thing you
know, you can't pass a FILE* around, either!

When you step back one level, you have the problem that memory
allocated with "malloc" can not be freed with "free" when the memory
crosses a 'libc border'.  The only real solution that I can see is not
to mix more than one libc into a single program.

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

If you can instruct code to use libguile.dll:scm_free instead of
kernel32.dll:free, can't you also instruct it to use msvcrt.dll:free
instead of kernel32.dll:free?

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405