Re: proposal: scm_string2str() and scm_symbol2str()

[Dirk Herrmann]

On Wed, 21 Nov 2001, stefan wrote:

> On Wed, 21 Nov 2001, Dirk Herrmann wrote:
> 
> > > 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?
> > 
> > I still don't get it.  How can those functions be named 'free' and these
> > people not getting conflicts with the standard library's free?  Don't they
> > use a different name for their 'personal free'?  I mean, if we allocate
> > our memory with 'malloc', then there has to be some appropriate 'free'
> > linked into the application, doesn't it?  Since we don't use a different
> > name than 'free' for the memory that guile frees, how can people get a
> > different one?
> 
> 1. There are different memory allocation API's.
> 2. Thereby "free()" and "malloc()" can have different meanings.
> 3. This is *not* a problem inside a monolithic executable, because
>    "free()" and "malloc()" match each other.
> 4. This is a *real* problem if you create a DLL (namely libguile.dll)
>    using *one* allocation API and create an executable linked against
>    this DLL and using *another* allocation API.
> 5. Therefor all this is not a problem inside libguile.
> 6. It is just a problem when you use libguile.
> 7. The problem can be avoided if you supply a "free()" and "malloc()" 
>    from inside libguile as I proposed.

If I understand your point correctly, _every_ library on a M$ system has
to provide its own version of free to the outside, given that it exchanges
allocated memory.  The outside code then has to keep track of memory
received from a library, because it has to make sure that it uses the
correct version of free, i. e. that version of free belonging to the
library from where it got that memory.  Basically, it is not possible to
pass allocated memory to a library and have that library free that memory,
except together with the memory you pass a pointer to the 'free' function
that should be used to free that memory.

Is this correct?

> Finally: For a clean memory interface of a client program to libguile 
> we use the following functions from libguile:
> 
>  * scm_c_malloc  -- should be used to allocate memory returned by some 
>                     of the SCM to C converter functions in libguile if the
>                     client program does not supply memory
>  * scm_c_free    -- must be used by the client program to free the memory
>                     returned by the SCM to C converter functions in 
>                     libguile if the client program did not supply a buffer
>  * scm_c_realloc -- to be complete, do not know a real purpose yet
> 
> 
> I start doubting my English is any good for.  Did you get the idea this
> time?

It is not a matter of language, but rather a matter of concepts.

> > Sorry, but I feel more and more that this support for M$ platforms
> > influences our code base in a bad way.
> 
> So why this?

I just dislike being forced to compromise clean code, using ANSI C
functions like malloc and free.  Good old 'extern' isn't good enough for
M$ folks either:  SCM_API has to be used everywhere, for reasons that I
don't understand from an ANSI C programmer's point of view.  (And, btw,
some macros and types also belong to our API, even if not prefixed with
SCM_API - just one aspect showing the uncleanlyness of that SCM_API
approach.)  What will be the next thing?  Adding more and more obscure
macros and functions will make the code more difficult to understand.  Is
this reason enough?

Best regards
Dirk Herrmann