Re: proposal: scm_string2str() and scm_symbol2str()

[Ken Raeburn]

Dirk Herrmann <address@hidden> writes:
> 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.

I'm not especially familiar with how the Windows tools work, but I've
talked with some Windows developers about such issues while working on
Kerberos at MIT.  We recently dropped nearly all the uses of
__declspec in our code.  I'm told that since we've got a symbol export
list provided in a file at DLL build time, we don't need to attach
__declspec to function declarations; Guile could probably do the same.
We do have a few variables exported from one library, and apparently
it's still an issue for them; those are most of the uses of __declspec
still remaining.  (The markers for explicitly choosing the Pascal
calling convention are the real headache, now.)

But that brings up the question of what would go into the export list.
Everything that's not declared static?  That includes anything that
should be considered internal to Guile but can't be made static
because more than one source file within Guile needs access to it.
IMHO an export list for the recommended API (plus backwards
compatibility for earlier versions etc) might be a good thing.  And
it's possible in at least some shared-library systems to implement
them as well.  (Look at ELF "filter" objects for example.)

Still, it should be possible to just export everything, though some
hacking might be needed if you want to generate the symbol list at
build time.  And that hacking would be in the Windows-specific DLL
generation part of the build process.


On the per-DLL malloc/free stuff, I'll just note that the Kerberos
library has free routines associated with most (all?) allocated data
types it can return, including strings.  Our structure internals are a
bit too exposed for it right now, but we've talked about taking
advantage of this to provide more efficient allocation on a per-type
basis.  (We have lots of cases where small objects contain many
pointers to other small objects, when we could perhaps combine the
allocations.)  But then we have to have all the right mutator
functions, make sure callers use them, etc.

Ken