Re: proposal: scm_string2str() and scm_symbol2str()

[stefan]

On Wed, 21 Nov 2001, Dirk Herrmann wrote:

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

This is correct for every DLL.  You can *use* allocated memory passed
through DLL bondaries, but you cannot *free()* it.

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

Since most of the functionality has now been ported to M$-Windows (except
the permission-user-group-owner API because Windows does not really know
about that) there will not be anymore obscure things... The major changes
have been done.  In fact the `diff -u' for a Windows
`guile-procedures.txt' with my Linux one is really small now !!!

Cheers,
        address@hidden