[M3devel] Problem interfacing C lib

Dragiša Durić dragisha at m3w.org
Thu Mar 22 12:08:10 CET 2012 

I'll try it soon, but I believe you are right.

That is only place in whole libevent where I met with struct return value. Everything else I tried works good.

dd

On Mar 21, 2012, at 8:35 PM, Jay wrote:

> 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/20120322/d3c5c06b/attachment-0002.html>

More information about the M3devel mailing list