Re: proposal: scm_string2str() and scm_symbol2str()

[stefan]

On Sun, 25 Nov 2001, Dirk Herrmann wrote:

> > I object to split the code into static/shared parts.
> 
> Well, I don't know enough about windows to claim that the static/shared
> solution is a big win.  But, I assume that many guile-using applications
> will write autoconf macros that configures the windows code to use some
> wrapper around scm_c_string2str to do the memory allocation.  The question
> is, whether we can make life easier for these folks?

Splitting libguile into a static and shared part would also split the
build process for Windows/Unix.  That is why I objected.

We could make life easier, if we supplied the following:

typedef void * (* scm_t_malloc_func) (size_t);
typedef void (* svz_t_free_func) (void *);

SCM_API scm_t_malloc_func scm_c_malloc = malloc;
SCM_API scm_t_free_func scm_c_free = free;

This piece of code would provide pointers to a free() and malloc() which
are by default "standard"s.  The malloc pointer should be used within
functions returning newly allocated memory which the user (a client
program of libguile) is meant to free() himself.  When a user sets its own
scm_c_malloc pointer before calling those functions,  he can safely free()
them.

This way nothing changes on the user side and the *not yet* implemented
SCM->C converters which need to allocate something must be using the above
scm_c_malloc() call.  Also nothing changes in the "Unix libguile user
world", because scm_c_malloc has a reasonable default.  Is this an
acceptable solution? 

Cheers,
        address@hidden