Re: proposal: scm_string2str() and scm_symbol2str()

[stefan]

On Thu, 22 Nov 2001, Dirk Herrmann wrote:

> > This is correct for every DLL.  You can *use* allocated memory passed
> > through DLL bondaries, but you cannot *free()* it.
> 
> Now, lets see if I can summarize the consequences of your suggestion:
> * On M$ systems, if you receive memory from inside of a DLL which you
>   once want to free, you _must_ use the version of free that is provided
>   by that DLL.  This means, if you pass this memory around, you will
>   always have to remember where you have got that memory from, because at
>   whatever place the memory will be freed, the correct version of free has
>   to be used.
> * For guile, you suggest to introduce scm_c_free as the name for the
>   'free' that would have to be used for freeing memory received from
>   guile.  That is, after scm_c_free is introduced, we should (according to
>   your suggestion) demand, that users of guile use 'scm_c_free' instead of
>   standard 'free' to free memory allocated by guile.
> 
> That would mean, users of guile - even on non M$ systems - would have to
> keep track where their memory came from?
> 
> Assume there are users which have some kind of hash table where they store
> strings in.  The hash table is responsible for removing entries from the
> table.  Now, if you want to put strings from guile as well as other
> strings into that table you would have to store a pointer to the
> corresponding version of 'free' with every string?  We should demand such
> coding from all guile users?

This is a bad thing I must admit.

> I object against the introduction of scm_c_free.  What about the following
> alternative solution:
> * on sane systems, scm_string2str is provided in guilelib.
> * on sick systems, we provide code for an implementation of
>   scm_string2str which has to be put into the _user_ code.  This version
>   of scm_string2str allocates the memory using the version of free that is
>   used within the user code.
> That is, in one case, scm_string2str is executed within guilelib, in the
> other case it is executed with the user code.  The interface is the same
> in both cases, that means that code that uses scm_string2str does not have
> to care about on which system it is executed.
> 
> Probably there are other ways to provide this functionality in a more
> elegant form:  Splitting guilelib on sick systems into a DLL and a static 
> library, where the static library holds the functions scm_string2str and
> friends.  Binding the static lib with the user code should make sure that 
> the same versions of malloc and free are used in both.
> 
> In any case I would say that the scm_c_free suggestion is inacceptable.

I suggest to omit all this stuff and implement scm_c_string2str() and the
remaining SCM->C converters which need to allocate memory as before in the
gh_*() interface, but always supply the extra argument (as in the gh_*()
interface) which will receive the returned memory if it is non-NULL.

Then we need to write a hint for users on "sick" (M$-Windows) systems when
they use libguile to supply this argument necessarily. It must not be
NULL if you are not sure the used libguile.dll does not use a malloc()
matching the client program's free().

I object to split the code into static/shared parts.

Is this acceptable?

> > > > 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 !!!
> 
> I still don't like it, sorry.  It won't fit into my head that there is not
> a single compiler on windows that offers a flag to make extern ==
> __declspec (foo) when compiling for a DLL (foo being either dllimport or
> dllexport).  It sucks that we have to obfuscate _our_ code because these
> people spit on the rest of the world.

This is kind of true.  But I think the latter discussions about
M$-Windows/Unix dues to nothing.  We should concentrate on Guile again :-)

Cheers,
        address@hidden