Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
Christopher Browne wrote:
;int SP_receive (
> char sender[MAX_GROUP_NAME],
> (sender (ffi:c-ptr ffi:char) :out)
This must be bogus.
Obviously (c-ptr (c-array[-max?] char MAX_GROUP_NAME))
Regarding the groups array, follow Sam's advice about variable length
1. it depends on your use-case whether max_groups is a constant for you,
in which case you could use an :out declaration with a known-size array.
2. it depends on the library provider whether/how slots between
num_groups and max_groups will be filled upon return. If there's
garbage, don't use :out as the conversion to Lisp strings might barf on
Then you need to go variable length. See examples.
> (endian-mismatch (ffi:c-ptr ffi:int) :out)
You MUST use :in-out since the API expects you to supply 0 on input.
Using :out, it would be left uninitialized -> garbage in, garbage out.
Same for mess_type.
> (message (ffi:c-ptr ffi:char) :out))
You probably are not interested in one-byte messages, are you?
Did you get error BUFFER_TOO_SHORT?
See above about known usable fixed-length or variable length.
Note that you may not be able to use a single def-c-call declaration
since the semantics of the parameters vary among REG_MESSAGE, TRANS_MESS
etc. (e.g. :out would yield garbage from unused parameters in