[M3devel] Problem interfacing C lib
Daniel Alejandro Benavides D.
dabenavidesd at yahoo.es
Wed Mar 21 04:30:42 CET 2012
Hi all:
Even when types are very similar, there is still a susceptibility to hit range checking problems. This is true if you see a [-n-1 .. n] not exactly comparable with the CHAR enumeration type (not talking about representation base).
So they are not subtypes of each other but also they are not subrange or included in the other as is.
This problem would be ameliorated by having a range interval safe machine, not exactly amd64 :(
Thanks in advance
--- El mar, 20/3/12, Mika Nystrom <mika at async.caltech.edu> escribió:
> De: Mika Nystrom <mika at async.caltech.edu>
> Asunto: Re: [M3devel] Problem interfacing C lib
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> CC: m3devel at elegosoft.com
> Fecha: martes, 20 de marzo, 2012 17:06
> 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
> >>
>
More information about the M3devel
mailing list