guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proposal: scm_string2str() and scm_symbol2str()


From: Dirk Herrmann
Subject: Re: proposal: scm_string2str() and scm_symbol2str()
Date: Thu, 22 Nov 2001 19:53:57 +0100 (MET)

On Thu, 22 Nov 2001, stefan wrote:

> On Wed, 21 Nov 2001, Dirk Herrmann wrote:
> 
> > 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.

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?

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.

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

Best regards
Dirk Herrmann




reply via email to

[Prev in Thread] Current Thread [Next in Thread]