Two new bugs, one easy the other not-so-easy.
1) Given the following IDL
> void foo([in] int s, [in,size_is(s)] double * bar);
In the marshalling code, the following line is generated after "primfoo
s bar"
> HDirect.freeref HDirect.freeDouble bar
Problem is, neither freeref nor freeDouble is defined. Obviously,
freeref is a typo for freeRef. trivialFree will work in place of
freeDouble in this instance, but I don't know if it will work in every
instance.
2) This one is a bit more tricky. I noticed that the array-of-strings
bug was fixed, but I've got more where that came from. :] I have an API
function that returns an array of strings, using reference varaibles.
(Actually it's [in,out] by reference, but it's the [out] that is causing
problems here.) It is defined in the header as follows:
> void gtk_init(int * argc, char *** argv);
The three *'s in the second parameter translates to: a reference(1) to
an array(2) of strings(3). I can't even figure out what the correct IDL
specification should be, if one is at all possible. The only way I can
think of getting this to fit into IDL would be to have the ordering of
the IDL attributes be significant. That would mean that
> void gtk_init([out] int * argc, [out,ref,size_is(*argc),string] char *** argv);
would mean a reference to an array of strings, whereas
> void gtk_init([out] int * argc, [out,size_is(*argc),ref,string] char *** argv);
would mean an array of references to strings. One could also try using
typedefs, but they come out awkward:
> typedef [string] char * str;
> typedef [size_is(*argc)] str * strArray;
> void gtk_init([out] int * argc, [out,ref] strArray * argv);
I'm afraid those are the only ideas that I've come up with. I can see a
similar issue with multi-dimentional arrays as well. (Somehow you've got
to correctly match up the size_is() attributes with their corresponding
dimentions.) Looks like significant ordering of attributes may be the
easiest way out.
Michael Hobbs
(HDirect 0.14)
