cvs commit: hugs98/src storage.c storage.h static.c machdep.c connect.h

[Alastair Reid]

"Ross Paterson" <ross@soi.city.ac.uk> writes:
>  But I don't understand how the API versioning works, when the
> version is selected by the interpreter rather than the DLL.

Sigbjorn's description of how it works describes the status quo but I
think we can/should look at changing it.

It is my intention that we should stop supporting code generated using
'greencard --target=hugs' since the --target=ffi code does at least as
much.  We should have a strategy to detect problems caused by dropping
support but no more.

So, looking at code generated using 'hugs +G', etc. what we're worried
about is people using code generated by old versions of Hugs where the
binary layout of the virtual table may be different.  The simplest way
to detect problems would be to have a simple consistency check.  For
example the 'API number' could be the release date for that Hugs
version (e.g. 03022003).  This should be inserted in the generated C
code.  Easy to maintain, works ok with binary packaging systems, will
require some recompilation sometimes.

We could get fancier (as Hugs was until a month or so ago) and maintain
the last few major versions of the binary API.  The only difference
here is thet the interpreter will accept one of several different API
versions.  More hassle to maintain for us, a bit easier for people
upgrading Hugs or maintaining binary packages.

My current feeling is that it's a good idea to check a version number
but that supporting more than one version of the binary API isn't
necessary.

--
Alastair

ps There are fancier variants on this plan where the generated code
   finds functions in the vtable by doing lookups like:

     cache.getInt8  = hugs->find_function(HUGS_GET_INT8);
     cache.getInt16 = hugs->find_function(HUGS_GET_INT16);
     cache.getInt32 = hugs->find_function(HUGS_GET_INT32);

   The lookup key would be like a COM UID - any change to the
   semantics of a function requires that the UID be changed.

   It'd be more tedious changing the code to be like this but easier to
   maintain in the long run.