On 10/08/12 09:51, David Matthews wrote:
On 08/08/2012 22:51, Phil Clayton wrote:
My bindings for GLib/GTK+ etc. involve some functions with 64 bit
parameter/return values, using the C types gint64/guint64 - GLib's
portable 64 bit integers. On Linux i386, these types are defined using
'signed/unsigned long long int'. I believe the C library stdint.h
defines portable types too, e.g. int64_t. (C99 provides 'long long int'
that is defined to be at least 64 bits.)
At present, I am working on GNU/Linux x86_64 where 'long' is 64 bits, so
the conversion LONG can be used to pass 64 bit values over the FFI.
However, I can't see a way to pass 64 bit values on platforms where
'long' is not 64 bits. Is there a way? I have no immediate need, but
I'm thinking that support for e.g. Linux i386 would be desirable at some
point.
Conversions such as LONGLONG/ULONGLONG could provide the FFI capability
on i386, where 'long long' is 64 bits. However, SML applications would
still need to choose between LONG and LONGLONG if 'long long' is larger.
So conversions such as INT64/UINT64 for exactly 64 bits on any
platform may be a better approach for a portable 64 bit C type. If I
have a moment, I'll have a look at foreign.cpp to see what is involved.
I think it would probably be a good idea to add a range of conversions
with and without explicit lengths, e.g. UINT64, LONGLONG and also
possibly INT_PTR and UINT_PTR.
Yes, that does sound good.
I have found the following tables on the MLton website useful:
http://mlton.org/ForeignFunctionInterfaceTypes
(I'm not sure that there is any need to distinguish between an implicit
and explicit signed qualifier though.)
I don't think it's difficult to do: it
needs changes in foreign.cpp in various places and also additions in the
higher-level parts of CInterface. I've added a few extra conversions,
such as "unsigned" at one time or another.
I had spotted those additions but haven't tried anything myself. To
save on effort, I was wondering about using sizes supplied by autoconf
for the platform-dependent types, so that they can be defined in terms
of the portable types or vice-versa.
Phil
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
