[M3devel] current tinderbox status, broken by me?

[Jay]

The C code I introduced should behave identically to or better than the Modula-3 code it  replaced. The Modula-3 code dependend on tedious error-prone rewriting of C headers in Modula-3.
Mistakes there easily lead to the overall safety of the system being violated.
 
I believe the C code adheres to the safety guarantee below.
Can you check?
 
 - Jay


________________________________
> Date: Tue, 30 Dec 2008 06:01:45 +0000
> From: dabenavidesd at yahoo.es
> To: m3devel at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] current tinderbox status, broken by me?
>
> In the case of adding procedures not in all the cases is Ok for INTERFACEs as pointed in the SPwM3 (green book, Chapter 6, page 156), also online available from ftp://gatekeeper.research.compaq.com/pub/DEC/SRC/research-reports/SRC-053.pdf " (page 26) "a module exporting a safe INTERFACE must guarantee that 'no programming error' by a safe client of that interface can lead to an unchecked runtime error."
> Following the same idea exposed there, is possible to call the RegularFile functions of FilePosix Interface and get runtime errors? which are the guarantees that protect from causing an unchecked runtime error?
> For instance a buggy code could use concurrently threads locking when writing the files concurrently, it will make a mess in the file and so may hole/leaks in memory? (could the file could be an IO port like parallel or serial)?
> I would like to
> hear your comments on that, let me know what else is missing to know the FilePosix is safe.
> Thanks in advance,
>
> --- El lun, 29/12/08, Jay wrote:
> De: Jay
> Asunto: [M3devel] current tinderbox status, broken by me?
> Para: "m3devel"
> Fecha: lunes, 29 diciembre, 2008 9:07
>
>
> NEXT Fatal Error: bad version stamps: SocketPosix.m3
> 4678
> 4679 version stamp mismatch: Compiler.Platform
> 4680 => SocketPosix.m3
> 4681 => Compiler.i3
> 4682 version stamp mismatch: Compiler.ThisPlatform
> 4683 => SocketPosix..m3
> 4684 => Compiler.i3
> 4685 NEXT *** execution of cm3
> -build
> -DROOT=´/home/m3/work/cm3-ws/birch.elegosoft.com-2008-12-30-01-00-04/cm3´
> -DCM3_VERSION_TEXT=´d5.7.0´ -DCM3_VERSION_NUMBER=´050700´
> -DCM3_LAST_CHANGED=´2008-03-16´ && cm3 -ship
> -DROOT=´/home/m3/work/cm3-ws/birch.elegosoft.com-2008-12-30-01-00-04/cm3´
> -DCM3_VERSION_TEXT=´d5.7.0´ -DCM3_VERSION_NUMBER=´050700´
> -DCM3_LAST_CHANGED=´2008-03-16´ failed ***
> 4686 compile return value: 0
> 4687 [end compile 2008.12.30 02:25:17]
> 4688 *** COMPILE FAILED
> No More Errors
>
>
> 1)
> Is it reasonable to suggest that the compiler output the source to clashing
> definitions?
> Or is that a bogus naive suggestion?
> It is probably legitimate, at least to identify the files in question.
> Could be that not enough information is around to identify "what
> changed", just some "summary hash".
>
>
> 2) Is it really broken?
> I did go slightly round and round on this.
> I
> had another new platform defined in one or another file and then when I
> backed down and just did one reasonly finished platform, I forgot at first to
> cleanup all the debris.
> But it certainly worked when I commited.
> I'm progressing on the native build, so if it is broken, I expect to run
> into it myself.
>
>
> 3) Is it reasonable to annotate a type with some sort of "relax, additions
> are safe" annotation?
> Probably not. It's probably too gray and more complicated than that, since
> additions in general are not as safe as people thing. Adding to a record --
> folks might be copying based on the size and might get back an older smaller
> version. Adding to an enum, folks might be switching on it and expect to have
> the range covered. Adding a function to an interface though, probably ok. Not
> the case here, and perhaps not something the compiler even complains about.
> One that that might be eek-out-able is adding to an
> enum, and such annotated
> types, switches on them must have an else clause, and they must not be used for
> array indexing?
> Eh, maybe just leave it alone.
>
>
> Anything else? Is this just basically how it has to be?
> OR, how about, can the duplicity be eliminated?
> Like, can Compiler.i3 be fully generated by the compiler?
> Similarly, Csetjmp.i3 should be generated by the compiler, eh?
> Or at least partly? You know, the size and alignment of the jmp_buf is
> recorded in both Csetjmp.i3 and Target..i3. Duplication is generally bad imho
>
>