[M3devel] Rv: Re: serial/Cygwin was Re: [M3commit] FilePosixC.c

[Jay]

another take on this..
 
 
Cloning C headers in Modula-3 is both error prone and unsafe.
It is not subject to static checking, is not verifiably correct,
and errors lead to the same sort of type system violations that
unsafe code can cause. I have found a few bugs here and there
in the cloned headers, mostly wrt alignment.
 
 
I replaced it with something probably still unsafe, but far less error prone.
 
 
 - Jay


________________________________
> Date: Thu, 25 Dec 2008 00:12:07 +0000
> From: dabenavidesd at yahoo.es
> To: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Rv: Re: serial/Cygwin was Re: [M3commit] FilePosixC.c
>
> 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 escribió:
> De: Mika Nystrom
> Asunto: Re: [M3devel] Rv: Re: serial/Cygwin was Re: [M3commit] FilePosixC.c
> Para: "Jay"
> 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  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  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  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  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  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  (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
>>>ll.edu> escribi=F3:
>>De: Jay Asunto: Re: [M3devel]
> serial/CygwinPara: "m3=
>>devel" =2C "Tony"
> 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
>>
>>

>>

>>
>>

>>

>>The real world is unsafe.
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.
=3B
=3B
I
> don't believe what I added is a=
>>ny more untrusted/unsafe than what was there before.
Well=2C maybe
> in a =
>>minor way.
=3B
=3B
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).
=3B=
>>
=3B
It is true I may have introduced external
> where it wasn't p=
>>reviously=2C but I don't think it matters.
It is prevalent one
> level dow=
>>n. Moving some of it one level up is ok
> I
> believe. =3B
=3B

>>
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
> in=
>>to separate files=2C "no" #ifdefs -- or conceptually each file
> can be viewe=
>>d as wrapped in an #ifdef or other platform detection.
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.

>>What is the 128 bit integer type to be called -- "__int128" or
> "long long l=
>>ong".

>> =3B

>> =3B

>>The names "char"=2C
> "short"=2C "int"=2C
> "long"=2C =3B"long long" =
>>=3Bare mostly just
> funny mistaken names.

>>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".

>>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.

>>
=3B

>>Not sure what "Posix" means=2C since it might incorporate
> by-reference ANSI=
>> C.

>> =3B

>> =3B
=3B-
> Jay




>>
>>
________________________________
> id=3DstopSpelling>
>>

>>
Date: Sat=2C 20 Dec 2008 00:09:41
> +0000
From:
> dabenavidesd at yahoo.es<=
>>BR>To: m3devel at elegosoft.com
Subject: [M3devel] Rv: Re:
> serial/Cygwin wa=
>>s Re: [M3commit] FilePosixC.c




>>

>>

>>

>> Dear all:
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.
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> class=3DEC_current-rev>*>>>EXTERNAL> class=3DEC_current-rev>*>=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.
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.
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.
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?
Thanks in
> advance



--- El vie=2C
> 19/12/08=2C J=
>>ay <=3Bjay.krell at cornell.edu>=3B
> escribi=F3:

>>
> 5px">De: Jay <=3Bj=
>>ay.krell at cornell.edu>=3B
Asunto: Re: [M3devel]
> serial/Cygwin
Para: =
>>"m3devel" <=3Bm3devel at elegosoft.com>=3B=2C
> "Tony" <=3Bhosking at cs.purd=
>>ue.edu>=3B
Fecha: viernes=2C 19 diciembre=2C 2008
> 1:25


>=
>>=3B And I'll fix SOLsun/gnu.

I /think/ it is ok now
> -- changing my "=
>>ino_t" to
"m3_ino_t".
I'm still
> checking though.
And I only
> checke=
>>d SOLgnu. I will check SOLsun.

-
> Jay

>

>>TD>


>>
=
>>
>>--_4c4a182e-6ca9-4b3c-a937-0fea11bffd83_--
>
>