[M3devel] Rv: Re: serial/Cygwin was Re: [M3commit] FilePosixC.c
Daniel Alejandro Benavides D.
dabenavidesd at yahoo.es
Thu Dec 25 01:12:07 CET 2008
Dear all,
actually I have found on The Modula-3 book of Harbison that it is expected to be exported safe INTERFACEs from safe and also UNSAFE MODULES, but the programmer should take care of the tournarounds of some failing ("not type safe checked") operations in the later case that could end crashing the entire systems without checked runtime error.
I agree that some important needs of this procedures are highly dependent on the platform/system specific helper procedures (please take a look of the old fashioned m3tohtml web page of http://www.cs.tut.fi/lintula/manual/modula3/m3sources/html/os/src/POSIX/FilePosix.m3.html of how the Unix operating system dependent UNSAFE INTERFACEs are isolated from the helper Procedures of Unix/POSIX platform for FilePosix UNSAFE MODULE and then become accesable through a safe FilePosix INTERFACE).
In fact this is supposed to disallow unchecked runtime errors as much as is possible to happen (maybe just at the most
operating system and specific level that is on m3core and not ever in libm3 which I think may be more secure than just type safe checked as I mentioned).
Definitely we need platform low level handling, say POSIX, WIN32 (possibly new WIN64 nowadays) specific code, but to do that is good rule of the thumb have the unsafe code like in those days of a huge number of supported operating system code (for UNIX and later for WIN32 platforms) that tells the system history.
Actually the Modula-3 compiler wouldn't be able to tell anything about C and if I'm not misunderstanding nor misinterpreting this mechanism of Modula-3 UNSAFE INTERFACE-UNSAFE MODULE -safe INTERFACE if I can make such a name was used to avoid unchecked runtime errors happened at pure Modula-3 parts of the system (such as libm3), and maybe a little more beyond that, having defined platform specific and operating system low level interfaces which can be more easily reworked.
You can read about this issue a bit more on the Partial Revelations article about safety issue http://modula3.elegosoft.com/pm3/pkg/modula3/src/discussion/partialRev.html .
Apart of that, I don't know if you would like the kind of documentation is reported on the SRC M3 generated file more than the corresponding one in nowadays (not produced every day I guess) http://opencm3.net/doc/help/gen_html/libm3/src/os/POSIX/FilePosix.m3.html I think could be useful to get back the same style of documentation procedures and correspondent files on this platform specific files (might be helpful to know where are the correspondant Interfaces on WIN platform as It wasn't on back days http://www.cs.tut.fi/lintula/manual/modula3/m3sources/html/os/src/WIN32/FileWin32..m3.html ).
Happy holidays and hope this helps a bit more.
--- El lun, 22/12/08, Mika Nystrom <mika at async.caltech.edu> escribió:
De: Mika Nystrom <mika at async.caltech.edu>
Asunto: Re: [M3devel] Rv: Re: serial/Cygwin was Re: [M3commit] FilePosixC.c
Para: "Jay" <jay.krell at cornell.edu>
CC: mika at camembert.async.caltech.edu
Fecha: lunes, 22 diciembre, 2008
10:49
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_--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20081225/d3be3ef1/attachment-0002.html>
More information about the M3devel
mailing list