[M3devel] Problem interfacing C lib

Wed Mar 21 20:35:13 CET 2012

Not good: don't return structs by value. Pass a pointer to where you want the result. 

 - Jay (briefly/pocket-sized-computer-aka-phone)

On Mar 21, 2012, at 5:25 AM, Dragiša Durić <dragisha at m3w.org> wrote:

> <* EXTERNAL evbuffer_search *>
> PROCEDURE search(buf: t; what: char_star; len: size_t; start: UNTRACED REF ptr): ptr;
> 
> <* EXTERNAL evbuffer_search_range *>
> PROCEDURE search_range(buf: t; what: char_star; len: size_t; start, end: void_star): ptr;
> 
> Tried both void_star and UNTRACED REF…
> 
> On Mar 21, 2012, at 12:59 PM, Antony Hosking wrote:
> 
>> Can you show your M3 interface declarations for these?
>> 
>> Sent from my iPad
>> 
>> On Mar 21, 2012, at 6:22 AM, Dragiša Durić <dragisha at m3w.org> wrote:
>> 
>>> Here are procedures I am binding. No nonsense, no #define hell. Clear and pure, and I don't see how I would write better and clearer :).
>>> 
>>> =====
>>> struct evbuffer_ptr
>>> evbuffer_search(struct evbuffer *buffer, const char *what, size_t len, const struct evbuffer_ptr *start)
>>> {
>>>         return evbuffer_search_range(buffer, what, len, start, NULL);
>>> }
>>> 
>>> struct evbuffer_ptr
>>> evbuffer_search_range(struct evbuffer *buffer, const char *what, size_t len, const struct evbuffer_ptr *start, const struct evbuffer_ptr *end)
>>> {
>>>    
>>> On Mar 21, 2012, at 5:35 AM, Jay K wrote:
>>> 
>>>> That is a bit wierd.
>>>> Lots of things seem wierd at first..and wierd even at second,
>>>> but often there are reasons things are how they are,
>>>> and often there are barriers to change.
>>>> 
>>>>  
>>>> I would expect Ctypes.char = CHAR.
>>>>  
>>>> 
>>>> But I don't know why it isn't.
>>>>  
>>>>  
>>>> I realize that CHAR ideally is some idealized abstract thing that can hold a unicode character.
>>>> But it isn't. It is 8 bits and will never be larger.
>>>>  
>>>>  
>>>> You are really best not to interface directly to C that you didn't write
>>>> and the C that you write that you interface to, you are best restricting
>>>> to a subset of C.
>>>>  
>>>> 
>>>> And use m3-libs/m3core/src/unix for working examples.
>>>>  
>>>> 
>>>> I remember when I added "BITS FOR" in Ctypes, it broke stuff.
>>>> I either didn't commit that or later removed it, leaving things as they
>>>> have been historically.
>>>>  
>>>>  
>>>>  - Jay
>>>> 
>>>> > To: dabenavidesd at yahoo.es
>>>> > Date: Tue, 20 Mar 2012 15:06:59 -0700
>>>> > From: mika at async.caltech.edu
>>>> > CC: m3devel at elegosoft.com
>>>> > Subject: Re: [M3devel] Problem interfacing C lib
>>>> > 
>>>> > char_star is, at least in my installation
>>>> > 
>>>> > UNTRACED REF [-16_7f-1 .. 16_7f]
>>>> > 
>>>> > But it's a good point that it's not actually an UNTRACED REF ARRAY OF CHAR
>>>> > 
>>>> > However 
>>>> > 
>>>> > ADR(chars[0]) 
>>>> > 
>>>> > ought to be more or less precisely of the type char_star
>>>> > 
>>>> > ... so I doubt that is the problem.
>>>> > 
>>>> > I'm curious about whether the assembly code for the call changes without
>>>> > the <*EXTERNAL*> pragma... it shouldn't should it? In which case, where
>>>> > is chars passed, in pure Modula-3 code? I don't know enough about the
>>>> > standard ABI of amd64 to know what the code should look like I'm afraid.
>>>> > 
>>>> > Mika
>>>> > 
>>>> > "Daniel Alejandro Benavides D." writes:
>>>> > >Hi all:
>>>> > >I think the unchecked error lays down to:
>>>> > >Unsafe Operations section 2.7 (cf. Green Book SPWM3, p- 61):
>>>> > >it's allowed to have " ... a value of type ADDRESS to be assigned to a vari=
>>>> > >able of type UNTRACED REF T. It is an unchecked runtime error if the value =
>>>> > >does not address a variable of type T."
>>>> > >
>>>> > >which could be reads conversely as:
>>>> > >
>>>> > >a value of type UNTRACED REF T to be assigned to a variable of type ADDRESS=
>>>> > >. It is a checked runtime error if the variable does not address a var=
>>>> > >iable of type .T=20
>>>> > >=20
>>>> > >And because because char_star is a subrange [-128 .. 127] OF INTEGER (and n=
>>>> > >ot ADDRESS) and chars is UNTRACED REF ARRAY OF CHAR erro is cf. the specif=
>>>> > >ication.
>>>> > >So maybe you need to change your char_star
>>>> > >
>>>> > >Thanks in advance
>>>> > >
>>>> > >
>>>> > >--- El mar, 20/3/12, Dragi=C5=A1a Duri=C4=87 <dragisha at m3w.org> escribi=C3=
>>>> > >=B3:
>>>> > >
>>>> > >> De: Dragi=C5=A1a Duri=C4=87 <dragisha at m3w.org>
>>>> > >> Asunto: Re: [M3devel] Problem interfacing C lib
>>>> > >> Para: "Mika Nystrom" <mika at async.caltech.edu>
>>>> > >> CC: m3devel at elegosoft.com
>>>> > >> Fecha: martes, 20 de marzo, 2012 01:04
>>>> > >> Errorr is SIGSEGV.
>>>> > >>=20
>>>> > >> chars is UNTRACED REF ARRAY OF CHAR but it is lesser
>>>> > >> problem, I think. It looks like formal 'what' is not
>>>> > >> sent at all!? It's place is taken by next argument - INTEGER
>>>> > >> len (equal 0x7 in this example).
>>>> > >>=20
>>>> > >> One common problem I meet often (as I bind C often :) is
>>>> > >> this - address of open array argument is ot what it looks
>>>> > >> like. To be sure you are getting address of various UNTRACED
>>>> > >> REF..ARRAY.. and open array procedure arguments - use=20
>>>> > >>=20
>>>> > >> ADR(chars[0])
>>>> > >>=20
>>>> > >> and do not use:
>>>> > >>=20
>>>> > >> LOOPHOLE(chars, ADDRESS)
>>>> > >>=20
>>>> > >> Of course, I tried ADR(chars[0]) :) - Same thing happened.
>>>> > >> Right now II downgraded my code to use strstr(3), but this
>>>> > >> argument passing still bugs me.
>>>> > >>=20
>>>> > >> dd
>>>> > >>=20
>>>> > >>=20
>>>> > >> On Mar 20, 2012, at 1:26 AM, Mika Nystrom wrote:
>>>> > >>=20
>>>> > >> > What are the declarations of all the variables involved
>>>> > >> in the call?
>>>> > >> >=20
>>>> > >> > And what is the actual error? Is it a SIGBUS,
>>>> > >> SIGSEGV?
>>>> > >> >=20
>>>> > >> > =3D?utf-8?Q?Dragi=3DC5=3DA1a_Duri=3DC4=3D87?=3D writes:
>>>> > >> >> I had some error before I LOOPHOLEd it.
>>>> > >> >>=20
>>>> > >> >> On Mar 19, 2012, at 7:27 PM, Daniel Alejandro
>>>> > >> Benavides D. wrote:
>>>> > >> >>=20
>>>> > >> >>> Hi all:
>>>> > >> >>> if chars is ADDRESS type why are you
>>>> > >> LOOPHOLE'ing it?=3D20
>>>> > >> >>> Thanks in advance
>>>> > >> >>> =3D20
>>>> > >> >>> --- El lun, 19/3/12, Dragi=3DC5=3DA1a Duri=3DC4=3D87
>>>> > >> <dragisha at m3w.org>
>>>> > >> =3D
>>>> > >> >> escribi=3DC3=3DB3:
>>>> > >> >>> =3D20
>>>> > >> >>>> De: Dragi=3DC5=3DA1a Duri=3DC4=3D87 <dragisha at m3w.org>
>>>> > >> >>>> Asunto: [M3devel] Problem interfacing C
>>>> > >> lib
>>>> > >> >>>> Para: "m3devel" <m3devel at elegosoft.com>
>>>> > >> >>>> Fecha: lunes, 19 de marzo, 2012 12:13
>>>> > >> >>>> #1 0x00000035bd8172a0 in
>>>> > >> >>>> evbuffer_search_range (buffer=3D3D0x694090,
>>>> > >> what=3D3D0x7 <Address
>>>> > >> >>>> 0x7 out of bounds>, len=3D3D0,
>>>> > >> start=3D3D0x0,
>>>> > >> >>>> end=3D3D0x7fffffffdbb0)
>>>> > >> >>>> at buffer.c:2441
>>>> > >> >>>> #2 0x0000000000404a0c in
>>>> > >> Buffer__Search (t=3D3D<error
>>>> > >> >>>> reading variable>, pattern=3D3D<error
>>>> > >> reading
>>>> > >> >>>> variable>, from=3D3D<error reading
>>>> > >> variable>,=3D20
>>>> > >> >>>> to=3D3D<error reading
>>>> > >> variable>) at
>>>> > >> >>>> ../src/Buffer.m3:150
>>>> > >> >>>> =3D20
>>>> > >> >>>> Buffer.m3:150
>>>> > >> >>>> pos :=3D3D
>>>> > >> >>>> evbuffer.search_range(t.b, LOOPHOLE(chars,
>>>> > >> ADDRESS), len,
>>>> > >> >>>> NIL, NIL);
>>>> > >> >>>> =3D20
>>>> > >> >>>> t.b is a pointer, so is chars=3DE2=3D80=3DA6 len
>>>> > >> is Utypes.size_t and
>>>> > >> >>>> it's value is 7.
>>>> > >> >>>> =3D20
>>>> > >> >>>> <* EXTERNAL evbuffer_search_range *>
>>>> > >> >>>> PROCEDURE search_range(buf: t; what:
>>>> > >> char_star; len: size_t;
>>>> > >> >>>> start, end: UNTRACED REF ptr): ptr;
>>>> > >> >>>> =3D20
>>>> > >> >>>> t is an ADDRESS, and so on=3DE2=3D80=3DA6
>>>> > >> >>>> =3D20
>>>> > >> >>>> Critical Mass Modula-3 version d5.9.0
>>>> > >> >>>> last updated: 2010-07-21
>>>> > >> >>>> compiled: 2010-10-04 07:24:16
>>>> > >> >>>> configuration: /etc/cm3.cfg
>>>> > >> >>>> host: AMD64_LINUX
>>>> > >> >>>> target: AMD64_LINUX
>>>> > >> >>>> =3D20
>>>> > >> >>>> =3D20
>>>> > >> >>>> Any ideas? TIA,
>>>> > >> >>>> dd
>>>> > >> >>>> =3D20
>>>> > >> >>>> =3D20
>>>> > >>=20
>>>> > >>
>>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120321/380e7f14/attachment-0002.html>