[M3devel] Rv: Re: serial/Cygwin was Re: [M3commit] FilePosixC.c
Mika Nystrom
mika at async.caltech.edu
Tue Dec 23 04:49:25 CET 2008
I think Daniel has a point. He said "UNSAFE", not "unsafe". "UNSAFE"
means something very specific in Modula-3, and operations that are
UNSAFE are only permitted to be exported by UNSAFE INTERFACEs and
hence only can be used in UNSAFE MODULEs.
If, however, there are UNSAFE interfaces in non-UNSAFE INTERFACEs, that
is a problem that really shouldn't be allowed to get worse.
This is all covered in sections 1.4.5 and 2.1 of the Green Book.
I'm not sure exactly what you guys are talking about but I would
appreciate it if I could rely on the Green Book for programming in
Modula-3....
Not everything that's <*EXTERNAL*> is UNSAFE, by the way. It is
perfectly possible for a routine coded in C or Fortran to export a
non-UNSAFE Modula-3 interface. Conversely, a Modula-3 MODULE can
definitely export an UNSAFE interface.
I think if you interpret section 2.1 a bit loosely, but I think
still within the spirit of the authors' intent, you can go as far
as to say that it's OK to introduce UNSAFE code (even in non-UNSAFE
interfaces) as long as the program needs to use at least one UNSAFE
INTERFACE in order to trigger the error. The contrapositive of
this is that it should not be possible for a Modula-3 program that
imports only non-UNSAFE interfaces to cause an unchecked runtime
error. Ever.
Some examples...., in the following, assume that CrashHorribly
can cause an unchecked runtime error when called.
INTERFACE A; TYPE T = BRANDED ROOT; END A.
UNSAFE INTERFACE B; IMPORT A; TYPE T <: A.T; END B.
UNSAFE INTERFACE C; IMPORT A; PROCEDURE CrashHorribly(arg : A.T); END C.
This is OK since an importer has to be UNSAFE to trigger CrashHorribly.
INTERFACE A; TYPE T = BRANDED ROOT; END A.
INTERFACE B; IMPORT A; TYPE T <: A.T; END B.
UNSAFE INTERFACE C; IMPORT A; PROCEDURE CrashHorribly(arg : A.T); END C.
Still OK, an importer still has to be UNSAFE to trigger CrashHorribly.
INTERFACE A; TYPE T = BRANDED ROOT; END A.
UNSAFE INTERFACE B; IMPORT A; TYPE T <: A.T; END B.
INTERFACE C; IMPORT A; PROCEDURE CrashHorribly(arg : A.T); END C.
Might be OK, as long as the only way to get an unchecked runtime
error in C is by passing in a B.T. If you can get an unchecked
runtime error in C.CrashHorribly without importing B (say by passing
in a bare A.T or a "home-made" subtype of A), it's wrong.
INTERFACE A; TYPE T = BRANDED ROOT; END A.
INTERFACE B; IMPORT A; TYPE T <: A.T; END B.
INTERFACE C; IMPORT A; PROCEDURE CrashHorribly(arg : A.T); END C.
Definitely wrong.
Mika
Jay writes:
>--_4c4a182e-6ca9-4b3c-a937-0fea11bffd83_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>The real world is unsafe.Safe areas are created by unsafe code=2C which mus=
>t be=2C to a certain extent=2C bug free=2C in order to provide as safe as a=
>dvertised. I don't believe what I added is any more untrusted/unsafe than =
>what was there before.Well=2C maybe in a minor way. m3core has "lots" of "=
>external" functions=2C which are called by "lots" of functions at higher le=
>vels..ok=2C maybe not "lots"=2C but if you look at the m3core/src/unix dire=
>ctories that I have worked on -- cygwin=2C openbsd=2C amd64_linux=2C linux-=
>common -- this is a fairly minimal set of stuff that is being used by preex=
>isting code. A LITTLE bit I added beyond what was there. If you look at all=
> the other directories=2C you'll find lots more external stuff=2C most of w=
>hich is not used within the CM3 codebase (but could be used by folks outsid=
>e). It is true I may have introduced external where it wasn't previously=
>=2C but I don't think it matters.It is prevalent one level down. Moving som=
>e of it one level up is ok I believe. =20
>Non-Posix does potentially have a place in .c files.It depends.Basically=2C=
> as I see things=2C a small amount of #ifdef is ok.A lot of #ifdef becomes =
>hard to read=2C and at some point=2C you split the files into separate file=
>s=2C "no" #ifdefs -- or conceptually each file can be viewed as wrapped in =
>an #ifdef or other platform detection.You need #ifdef in any C that uses 64=
> bit integers=2C for example. Current Microsoft compilers do support "long =
>long" but __int64 supporg goes way back=2C and __int64 is a better name any=
>way.
>What is the 128 bit integer type to be called -- "__int128" or "long long l=
>ong".
>=20
>=20
>The names "char"=2C "short"=2C "int"=2C "long"=2C "long long" are mostly ju=
>st funny mistaken names.
>The right names to provide are explicitly sized=2C int8=2C uint8=2C int16=
>=2C uint16=2C int32=2C uint32=2C int64=2C uint64=2C and pointer sized types=
> such as "size_t" and "diff_t".
>Modula-3 I think is reasonable here=2C since it's primary integral type is =
>pointer sized=2C and it has "bits x for ..."=2C though the other types prob=
>ably ought to be built in and blessed somewhere=2C not just in the Csupport=
> library section.
>=20
>Not sure what "Posix" means=2C since it might incorporate by-reference ANSI=
> C.
>=20
> - Jay
>
>
>
>Date: Sat=2C 20 Dec 2008 00:09:41 +0000From: dabenavidesd at yahoo.esTo: m3dev=
>el at elegosoft.comSubject: [M3devel] Rv: Re: serial/Cygwin was Re: [M3commit]=
> FilePosixC.c
>
>
>
>Dear all:I'm glad that Jay and all the people around are making contributio=
>ns=2C so we can claim that as some day there were a good number of supporte=
>d platforms nowadays we also have.However I have a question=2C but its more=
> a suggestion=2C the modification Tony is referring is not as standard as w=
>e would like since the type safety is affected with the change introduced a=
>llowing <*EXTERNAL*> (untrusted) functions in the INTERFACE FilePosix=2C it=
>'s an implementation issue of the CM3 (IMHO it should warn) compiler=2C so =
>we may want to mark as UNSAFE INTERFACE=2C however doing that I think some =
>clients could not claim any more they are safe so that "fix" is not feasib=
>le.Can you push to a lower level (as in the UNSAFE FilePosix implementation=
> module before committing the change) or make it available in other Interfa=
>ce already available=2C why do we need that change anyway? Also IMHO we sh=
>ould leave out what is not POSIX (we should not care for WIN64 although I k=
>now is needed by the C compiler preprocessor) out of that file.Although I d=
>on't have the formal specification or program=2C but I can remember libm3 c=
>ode was specified and mechanically checked with the Extended Static Checker=
> Modula-3 (which is not sound also=2C that is could be cheated=2C see http:=
>//www.researchchannel.org/prog/displayevent.aspx?rID=3D2761&fID=3D345 )=2C =
> that would be a good reason for keeping as safe as possible and close to h=
>istorical interfaces and just rework implementations (even if they are not =
>safe) as needed. I know that implementation is not safe but at least having=
> it well enough implemented the ESC/M3 checker and the compiler would tell =
>us the library should work Ok and is safe and (hopefully) without the error=
>s detected by the ESC as we care for the details in the UNSAFE implementati=
>on.There are any special interfaces we should have as "standard" in the low=
>er level runtime (hard enough question I know)=2C can we give some hints/id=
>eas on that?Thanks in advance--- El vie=2C 19/12/08=2C Jay <jay.krell at corne=
>ll.edu> escribi=F3:
>De: Jay <jay.krell at cornell.edu>Asunto: Re: [M3devel] serial/CygwinPara: "m3=
>devel" <m3devel at elegosoft.com>=2C "Tony" <hosking at cs.purdue.edu>Fecha: vier=
>nes=2C 19 diciembre=2C 2008 1:25> And I'll fix SOLsun/gnu.I /think/ it is o=
>k now -- changing my "ino_t" to"m3_ino_t".I'm still checking though.And I o=
>nly checked SOLgnu. I will check SOLsun. - Jay =
>
>--_4c4a182e-6ca9-4b3c-a937-0fea11bffd83_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style>
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Verdana
>}
></style>
></head>
><body class=3D'hmmessage'>
>The real world is unsafe.<BR>Safe areas are created by unsafe code=2C which=
> must be=2C to a certain extent=2C bug free=2C in order to provide as safe =
>as advertised.<BR> =3B<BR> =3B<BR>I don't believe what I added is a=
>ny more untrusted/unsafe than what was there before.<BR>Well=2C maybe in a =
>minor way.<BR> =3B<BR> =3B<BR>m3core has "lots" of "external" funct=
>ions=2C which are called by "lots" of functions at higher levels..ok=2C may=
>be not "lots"=2C but if you look at the m3core/src/unix directories that I =
>have worked on -- cygwin=2C openbsd=2C amd64_linux=2C linux-common -- this =
>is a fairly minimal set of stuff that is being used by preexisting code. A =
>LITTLE bit I added beyond what was there. If you look at all the other dire=
>ctories=2C you'll find lots more external stuff=2C most of which is not use=
>d within the CM3 codebase (but could be used by folks outside).<BR> =3B=
><BR> =3B<BR>It is true I may have introduced external where it wasn't p=
>reviously=2C but I don't think it matters.<BR>It is prevalent one level dow=
>n. Moving some of it one level up is ok I believe. =3B<BR> =3B<BR>
><BR>Non-Posix does potentially have a place in .c files.<BR>It depends.<BR>=
>Basically=2C as I see things=2C a small amount of #ifdef is ok.<BR>A lot of=
> #ifdef becomes hard to read=2C and at some point=2C you split the files in=
>to separate files=2C "no" #ifdefs -- or conceptually each file can be viewe=
>d as wrapped in an #ifdef or other platform detection.<BR>You need #ifdef i=
>n any =3BC that uses 64 bit integers=2C for example. Current Microsoft&=
>nbsp=3Bcompilers do support "long long" but __int64 supporg goes way back=
>=2C and __int64 is a better name anyway.<BR>
>What is the 128 bit integer type to be called -- "__int128" or "long long l=
>ong".<BR>
> =3B<BR>
> =3B<BR>
>The names "char"=2C "short"=2C "int"=2C "long"=2C =3B"long long" =
>=3Bare mostly just funny mistaken names.<BR>
>The right names to provide are explicitly sized=2C int8=2C =3Buint8=2C =
>int16=2C uint16=2C int32=2C uint32=2C int64=2C uint64=2C and pointer sized =
>types such as "size_t" and "diff_t".<BR>
>Modula-3 I think is reasonable here=2C since it's primary integral type is =
>pointer sized=2C and it has "bits x for ..."=2C though the other types prob=
>ably ought to be built in and blessed somewhere=2C not just in the Csupport=
> library section.<BR>
><BR> =3B<BR>
>Not sure what "Posix" means=2C since it might incorporate by-reference ANSI=
> C.<BR>
> =3B<BR>
> =3B<BR> =3B- Jay<BR><BR><BR><BR>
>
><HR id=3DstopSpelling>
><BR>
><BR>Date: Sat=2C 20 Dec 2008 00:09:41 +0000<BR>From: dabenavidesd at yahoo.es<=
>BR>To: m3devel at elegosoft.com<BR>Subject: [M3devel] Rv: Re: serial/Cygwin wa=
>s Re: [M3commit] FilePosixC.c<BR><BR><BR><BR>
><TABLE cellSpacing=3D0 cellPadding=3D0 border=3D0>
><TBODY>
><TR>
><TD vAlign=3Dtop>Dear all:<BR>I'm glad that Jay and all the people around a=
>re making contributions=2C so we can claim that as some day there were a go=
>od number of supported platforms nowadays we also have.<BR>However I have a=
> question=2C but its more a suggestion=2C the modification Tony is referrin=
>g is not as standard as we would like since the type safety is affected wit=
>h the change introduced allowing <=3B<SPAN class=3DEC_current-rev>*</SPAN=
>>EXTERNAL<SPAN class=3DEC_current-rev>*</SPAN>>=3B (untrusted) functions =
>in the INTERFACE FilePosix=2C it's an implementation issue of the CM3 (IMHO=
> it should warn) compiler=2C so we may want to mark as UNSAFE INTERFACE=2C =
>however doing that I think some clients could not =3B claim any more th=
>ey are safe so that "fix" is not feasible.<BR>Can you push to a lower level=
> (as in the UNSAFE FilePosix implementation module before committing the ch=
>ange) or make it available in other Interface already available=2C why do w=
>e need that change anyway? =3B Also IMHO we should leave out what is no=
>t POSIX (we should not care for WIN64 although I know is needed by the C co=
>mpiler preprocessor) out of that file.<BR>Although I don't have the formal =
>specification or program=2C but I can remember libm3 code was specified and=
> mechanically checked with the Extended Static Checker Modula-3 (which is n=
>ot sound also=2C that is could be cheated=2C see http://www.researchchannel=
>.org/prog/displayevent.aspx?rID=3D2761&=3BfID=3D345 )=2C =3B that wo=
>uld be a good reason for keeping as safe as possible and close to historica=
>l interfaces and just rework implementations (even if they are not safe) as=
> needed. I know that implementation is not safe but at least having it well=
> enough implemented the ESC/M3 checker and the compiler would tell us the l=
>ibrary should work Ok and is safe and (hopefully) without the errors detect=
>ed by the ESC as we care for the details in the UNSAFE implementation.<BR>T=
>here are any special interfaces we should have as "standard" in the lower l=
>evel runtime (hard enough question I know)=2C can we give some hints/ideas =
>on that?<BR>Thanks in advance<BR><BR><BR><BR>--- El <B>vie=2C 19/12/08=2C J=
>ay <I><=3Bjay.krell at cornell.edu>=3B</I></B> escribi=F3:<BR>
><BLOCKQUOTE style=3D"PADDING-LEFT: 5px=3B MARGIN-LEFT: 5px">De: Jay <=3Bj=
>ay.krell at cornell.edu>=3B<BR>Asunto: Re: [M3devel] serial/Cygwin<BR>Para: =
>"m3devel" <=3Bm3devel at elegosoft.com>=3B=2C "Tony" <=3Bhosking at cs.purd=
>ue.edu>=3B<BR>Fecha: viernes=2C 19 diciembre=2C 2008 1:25<BR><BR><PRE>>=
>=3B And I'll fix SOLsun/gnu.<BR><BR>I /think/ it is ok now -- changing my "=
>ino_t" to<BR>"m3_ino_t".<BR>I'm still checking though.<BR>And I only checke=
>d SOLgnu. I will check SOLsun.<BR> <BR> - Jay<BR> </PRE></BLOCKQUOTE><BR></=
>TD></TR></TBODY></TABLE><BR></body>
></html>=
>
>--_4c4a182e-6ca9-4b3c-a937-0fea11bffd83_--
More information about the M3devel
mailing list