2011/6/5 keyd...@gmx.de <keyd...@gmx.de>: > [...] > The c function is described as > boolean OCI_BindArrayOfStrings(OCI_Statement * stmt, const mtext * name, > dtext * data, unsigned int len, unsigned int nbelem) > where mtext and dtext are aliases for char, the way the library was > compiled, the second-but-last argument has to indicate the length of the > longest string in the array, and the last argument has to be 0 apart from a > special case not applicable here. > I've defined it as > (def-ocilib bindstringarray OCI_BindArrayOfStrings : (stmt_ptr : _pointer) > (name : _string) (data : (_list i _string)) (maxstrlen : _uint = > (getmaxlength data)) (no : _uint) -> (result : _bool)) > where maxstrlen gives the length of the longest list member. > [...]
Hello Sigrid, if dtext is actually an alias for char, as you write, then the signature of the C function implies that it expects a string, not a list of strings, as its third argument. The second problem with the binding definition is that it doesn't convey any information about the length of the list to the C function, which is almost certain to cause trouble. Judging by your description of the C function's contract, simply adding a #f to the end of the list before passing it to the marshaller should do the job here: Just replace (data : ...) by (data : ... = (append data '(#f))). Finally, when passing ephemeral data like this array and the string pointers it contains to C, one has to be careful that the Racket garbage collector doesn't interfer with assumptions made on the C side about the incoming data: If the function doesn't copy the data but simply stores the pointers somewhere and returns, the data may be garbage collected before it is used again in some other C function, which of course will fail miserably in that case. > [...] > I also tried using > (data : (_list io _string (length data)) > instead, in order to check the correctness of the input strings, putting > them out as part of the functions return values, but for doing (length data) > I get the error > length: expects argument of type <proper list>; given #<cpointer> > so here data seems to be a c type, not a racket list anymore... > [...] I think that in the lexical scope where the expansion of the _list syntax inside the _fun syntax places the output argument length computation, the name of the output argument is bound to the raw pointer from C. You can circumvent this by using a different name for the argument of the Racket wrapper procedure and the argument of the C function — check the description of the _fun syntax for the maybe-args part. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
