Re: Interfacing with C questions

[Marek Janukowicz]

Hi

On Friday 04 of February 2011, Keith Hopper wrote:
> Hi,
>      I commiserate with your comment -
> 
> > However, more often than not, I *have* to interface with C and deal with
> > its weak typing approach. So if I ask about usage of C_SIZE_T type, it's
> > not because I'd like to abuse it, but because a C function expects
> > argument of size_t type and I'd like to satisfy it by providing properly
> > typed argument from Sather side instead of blindly using INT and hoping
> > for the best.
> 
>      Mmmm! While I understand your concern, there is absolutely no way
> that Sather and C typing are compatible except at the base 'bit-pattern'
> level. Any typing which you attempt boils down to understanding this
> limitation. EXT_OB is the Sather equivalent of (void *) - and any
> derivatives of that with an asterisk - ie a memory reference. Further
> semantics must be defined by the corresponding Sather class

Ok - that's what I thought. That's unfortunate (as bit level compatibility is 
quite error-prone), but now that I know there is no magic way around it I'll 
have to deal with it :)

> [...]
> > However, it doesn't really answer my biggest
> > question - how do I convert somewhat larger C data structure (the
> > infamous char ***listptr) from C to Sather? Your answer "You can do this
> > in the same sort of way that the Sather 1.3 stuff was done" doesn't tell
> > me much as I don't know where and what to look for (if you mean that
> > SOCKET class - there are only trivial C types returned from C calls
> > there).
> 
>      OK! (char ***listptr) is a list of lists of lists. So Do this one
> step at a time  Using arbitrary names - convert to an EXT_OB given the
> Sather type ALIST. This is, of course a list in C terms of (char
> **alistptr). Do the same to BLIST which is a list of C strings - then,
> finally create the individual Sather strings using
> "create_from_c_string". I can't remember if there is a routine
> "create_from_null_terminated_list" but it shouldn't be difficult to
> produce one. You will, however, need to have a 'level' parameter so that
> the structure 'ptr', 'ptr','nil', 'ptr', 'ptr, 'nil', 'nil' is correctly
> unhatched as a two element array of pointers to two element arrays.
> 
>      If you are going to have varying numbers of elements in each list
> then you will need to use actual lists rather than arrays.
> 
>      Does this help?

Yeah, it certainly does - thanks. Although I noticed libpcre also has some 
additional API calls that are better suited to my needs.

-- 
Marek Janukowicz