[M3devel] Problem interfacing C lib

Dragiša Durić dragisha at m3w.org
Wed Mar 21 13:25:10 CET 2012 

<* 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/a7880df6/attachment-0002.html>

More information about the M3devel mailing list