[M3devel] Problem interfacing C lib

Wed Mar 21 05:35:37 CET 2012

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 theyhave 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/db185600/attachment-0002.html>