On Sat, Dec 31, 2016 at 06:52 AM, Don Ward wrote:
On 30 Dec 2016, at 03:34, btif...@vivaldi.net (mailto:btif...@vivaldi.net)
wrote:
Jafar, Clinton; I need a little education on the new mkExternal feature in
icall.h, as I could not get a working sample. Currently, pointer data is just
sent back as an integer handle (which will break on some platforms), and I'd
like to extend the supported types to C structs and pointers to memory blocks,
etc. I hope that just a short working example on what the actual C data type
declaration is to start running with it; could not tell from the macro, so I
thought I'd just ask instead of flailing about.
I’m guessing we’re talking about revision 4642 here. If so, the “guilty party”
is me. The intention is that an external value is an opaque type: something
that is generated by the C code, passed into the Unicon code and given back as
required. The Unicon code should not manipulate it or poke around inside it
—it’s supposed to be opaque — just give it back to the C code when needed.
A good example of it’s use (which will be coming to a distribution near you
fairly soon, I hope) is the way that RFC6234 handles the secure hash context.
The context, which is created by the routines, is passed back to the caller,
which gives it back to the hash routine for each subsequent operation.
I hope that makes things a bit clearer. Sorry for the confusion, but the RF6234
code, which would have provided an example of how to use mkExternal, is still
in the works, awaiting some changes to how things are organised.
Regards
Don
Thanks, Don.
I'm starting to get my head around it a little more. It will come in handy on
the next update of uniffi, as I'll be adding struct data passing and return
types.
It took a little while to unsquirrel the list management, and I'll be asking
for feedback on how that might be improved on, and strengthened. I had to add
the b_elem struct to my local copy of icall.h to make it easier on the brain,
but then stumbled into how IListVal and RListVal works, and went from there. It
is simpler now, then when I was flailing, but I'm not overly sure it's safer or
the most efficient.
libffi and calling C routines without loadfunc is pretty handy (and much fun).
The libffi cut has a lot of platforms covered, including s390 z/Linux, and
Windows and Mac, and FreeBSD and on and on. Making for some pretty neat
experiments.
Listings are up at,
http://btiffin.users.sourceforge.net/up/multilanguage.html#libffi
(http://btiffin.users.sourceforge.net/up/multilanguage.html#libffi)
Still work to do, a lot more tests, adding in all the data subtypes, etc. But
it already covers a lot of bases. And not that much code. Worked out the
double/float typing problem by using a two element list for arguments that need
to be demoted. There is more subtyping to do, and figure out some way of
allowing mutable call by content without risking Unicon core types. It'll
almost assuredly come down to make temporary or tended copies, and adding
another function for accessing the result sets (might be lists, records,
encoded strings, whatever structure it ends up looking like for the Unicon
programmer side).
Have good, happy 2017 everyone,
Brian
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Unicon-group mailing list
Unicon-group@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unicon-group
