<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
I'm making the system more safe, not less.<BR>
<BR>
<BR>
The previous methodology was tedious, error prone, and didn't get any sort of checking.<BR>
<BR>
<BR>
Whatever was declared in the *.i3 files was presumed correct.<BR>
<BR>
<BR>
The linkage from the next layer to this layer gets the same amount of checking as it used.<BR>
<BR>
<BR>
The link you point to shows people fixing things the same way as I am making them.<BR>
<BR>
<BR>
unix/*.i3 must use <*EXTERNAL*> to declare C functions.<BR>
That is what it did. That is what it does.<BR>
Extend this out slightly to m3core/libm3.<BR>
Same thing.<BR>
The difference is whether or not those C functions are implemented right there, once, plain to see that they match the <*EXTERNAL*> declarations, or whether they are in a per-platform /usr/include and source tree somewhere, with tedious and error prone and per-platform verification as to if they are correct. As well as copy/pasting where there the "API" might be a macro.<BR>
<BR>
<BR>
Really, I am making the system more safe, not less.<BR>
There is no loss in checking but there is more obvious correctness by human inspection in what must be unsafe, one way or another.<BR>
<BR>
<BR>
The result is also more portable.<BR>
<BR>
<BR>
- Jay<BR> <BR>
<HR id=stopSpelling>
Date: Mon, 16 Mar 2009 17:14:35 -0700<BR>From: dabenavidesd@yahoo.es<BR>To: hosking@cs.purdue.edu; jay.krell@cornell.edu<BR>CC: m3devel@elegosoft.com<BR>Subject: Re: [M3devel] recent problems?<BR><BR>
<TABLE cellSpacing=0 cellPadding=0 border=0>
<TBODY>
<TR>
<TD vAlign=top>Hi all:<BR>well, I know more about the kind of work done recently, which I can not just say is unsafe, but putting a layer of C code that obviously is dependent of each Linux/Unix, I guess in the past this is not always true, but having each Linux it's own headers and different implementations makes more unstable the system.<BR>Besides the type checking made by C Compiler is not checked at link time, in contrast of Modula-3 that type checks whenever interfaces are changed and checks on link time.<BR>So if you put change in your C code doesn't mean that Modula-3 will catch common silly but common true errors, like buffer overflows that if not checked at run time will crash (almost always) at runtime of a safe program, and it will not be safe (hidden code is beyond the Modula-3 compiler).<BR>I strongly support simplifying and factoring as much as possible, but try to use what is there in Modula-3, not re-implementing in another Language if possible at all. I know but even more, the idea of having linking with C code on the kernel system calls allows to protect from so called side effects of Kernel code. Memory protection is exhausted here.<BR>But when using true library user space system calls, this puts in a dangerous side the untrusted code. Here I reclaim again not using more that true system calls. I see that this started to be harder with AMD64 or x86_64 current platforms, so further development may be needed here see http://edoofus.blogspot.com/2008/08/interesting-bug-unbreaking-cvsupamd64.html about ezm3 related problems, is this supposed to be handled in Cm3 like the same they did?<BR>Jay and all seem to do the better job they can, but I don't want to miss the opportunity to say this if I may. I will tell you later more about the type system If this it is useful to be said.<BR><BR>Thanks in advance<BR><BR>--- El <B>lun, 16/3/09, Jay <I><jay.krell@cornell.edu></I></B> escribió:<BR>
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px">De: Jay <jay.krell@cornell.edu><BR>Asunto: Re: [M3devel] recent problems?<BR>Para: "Tony" <hosking@cs.purdue.edu><BR>CC: "m3devel" <m3devel@elegosoft.com><BR>Fecha: lunes, 16 marzo, 2009 3:55<BR><BR><PRE>It's ok on LINUXLIBC6 with the "new headers" but<BR>I believe PPC_DARWIN problem caused by them so <BR>backed out pending debugging.<BR>This one looks easy to solve, though my time<BR>is scarser next week or two.<BR> <BR>I should have maybe considered:<BR> "new headers" used on a number of Linux systems already <BR> but no Darwin systems yet <BR> <BR> - Jay<BR><BR><BR>----------------------------------------<BR>> From: hosking@cs.purdue.edu<BR>> To: jay.krell@cornell.edu<BR>> Date: Tue, 17 Mar 2009 01:54:34 +1100<BR>> CC:
m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] recent problems?<BR>><BR>> This is worrying as it seems some level of instability has been<BR>> introduced by recent changes. mentor used to be fine.<BR>><BR>> On 17 Mar 2009, at 00:16, Jay wrote:<BR>><BR>>><BR>>> mklib seems ok now, having started over with a new checkout, new<BR>>> build.<BR>>> Strange considering what I had already tried, this problem had been<BR>>> plaguing me over a week.<BR>>><BR>>><BR>>> stubgen doesn't hang with 1.5, will try 1.7 again/later.<BR>>><BR>>><BR>>> But formsedit still crashes during startup intermittently,<BR>>> and Cygwin X apps hang at startup.<BR>>> ugh.<BR>>> I know, I probably caused whatever problem..<BR>>><BR>>><BR>>> - Jay<BR>>><BR>>><BR>>><BR>>> ----------------------------------------<BR>>>> From:
jay.krell@cornell.edu<BR>>>> To: hosking@cs.purdue.edu<BR>>>> CC: m3devel@elegosoft.com<BR>>>> Subject: RE: [M3devel] recent problems?<BR>>>> Date: Mon, 16 Mar 2009 08:57:40 +0000<BR>>>><BR>>>><BR>>>> Thanks.<BR>>>><BR>>>><BR>>>> Here is another one.<BR>>>> I found this testing moving PPC_DARWIN to "my headers".<BR>>>> formsedit crashes during startup roughly more than<BR>>>> half the times I start up, but not every time.<BR>>>> The stack is always the same.<BR>>>> I'll test it without my change.<BR>>>> I think it'll happen either way, but I'll see.<BR>>>> Yes, it recurs without my change, though I double<BR>>>> check that my change is really undone.<BR>>>> I'll have to dig into this.<BR>>>><BR>>>><BR>>>> How does one get the code from CVS corresponding to a
date?<BR>>>> cvs upd -D ?<BR>>>> I'll try that or something, see if I can find when things<BR>worked.<BR>>>><BR>>>><BR>>>> I should also be able to try the mklib crashing scenario<BR>>>> on other platforms. It normally doesn't run on other<BR>platforms.<BR>>>><BR>>>><BR>>>> stubgen..if I'm ambitious, I can run in a loop on another<BR>platform.<BR>>>> But I think just moving Cygwin off of pthreads will<BR>"fix" it<BR>>>> and provide a cleaner base (not due to pthreads, but the Cygwin<BR>>>> stuff).<BR>>>><BR>>>><BR>>>> Program received signal EXC_BAD_ACCESS, Could not access memory.<BR>>>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000004<BR>>>> [Switching to process 19583 thread 0x2643]<BR>>>> 0x0031798c in ScrollerVBTClass__PaintViewWithShadows<BR>>>> (M3_Ao3CED_v=0x1f1eef4) at
../src/lego/POSIX/Sc<BR>>>> rollerVBTClass.m3:325<BR>>>> 325 VBT.PaintTint(v, r, v.shadow.bg);<BR>>>> (gdb) bt<BR>>>> #0 0x0031798c in ScrollerVBTClass__PaintViewWithShadows<BR>>>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSI<BR>>>> X/ScrollerVBTClass.m3:325<BR>>>> #1 0x0031766c in ScrollerVBTClass__PaintView<BR>>>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV<BR>>>> BTClass.m3:292<BR>>>> #2 0x0031a460 in ScrollerVBTClass__Repaint (M3_Ao3CED_v=0x1f1eef4,<BR>>>> M3_A0Kbc5_rgn=0xf0284778) at ../<BR>>>> src/lego/POSIX/ScrollerVBTClass.m3:693<BR>>>> #3 0x0031a590 in ScrollerVBTClass__Redisplay<BR>>>> (M3_Ao3CED_v=0x1f1eef4) at ../src/lego/POSIX/ScrollerV<BR>>>> BTClass.m3:706<BR>>>> #4 0x005c2870 in VBTClass__Redisplay (M3_BFdKo9_v=0x1f1eef4) at<BR>../<BR>>>> src/vbt/VBTClass.m3:367<BR>>>>
#5 0x005cf1c0 in VBTRep__Redisplay () at ../src/vbt/VBTRep.m3:652<BR>>>> #6 0x005ce59c in VBTRep__UncoverRedisplay () at ../src/vbt/<BR>>>> VBTRep.m3:601<BR>>>> #7 0x005ce724 in VBTRep__RdApply (M3_EMTrVz_self=0x1d554c8) at ../<BR>>>> src/vbt/VBTRep.m3:606<BR>>>> #8 0x0132ff88 in ThreadPThread__RunThread (M3_ChNkUD_me=0x1e23940)<BR>>>> at ../src/thread/PTHREAD/ThreadP<BR>>>> Thread.m3:531<BR>>>> #9 0x0132fb58 in ThreadPThread__ThreadBase<BR>>>> (M3_AJWxb1_param=0x1e23940) at ../src/thread/PTHREAD/Thr<BR>>>> eadPThread.m3:508<BR>>>> #10 0x9002b908 in _pthread_body ()<BR>>>> (gdb)<BR>>>><BR>>>><BR>>>><BR>>>> - Jay<BR>>>><BR>>>><BR>>>><BR>>>> ----------------------------------------<BR>>>>> From: hosking@cs.purdue.edu<BR>>>>> To:
jay.krell@cornell.edu<BR>>>>> Date: Mon, 16 Mar 2009 08:10:05 +1100<BR>>>>> CC: m3devel@elegosoft.com<BR>>>>> Subject: Re: [M3devel] recent problems?<BR>>>>><BR>>>>> You might have structure sizes wrong and your stack will get<BR>shifted<BR>>>>> around as the command line changes length. You get some data<BR>in a<BR>>>>> structure wrong and then hit the wrong stack org and you might<BR>see<BR>>>>> problems like this.<BR>>>>><BR>>>>> I am not running things totally off of the head, so if the<BR>problem<BR>>>>> was<BR>>>>> introduced recently it might only now be seen.<BR>>>>><BR>>>>> On 16 Mar 2009, at 06:15, Jay wrote:<BR>>>>><BR>>>>>><BR>>>>>> I'm seeing some problems lately. Maybe it is just me.<BR>>>>>> Some of them I've had over
a week (ie: before my<BR>(most) recent<BR>>>>>> changes),<BR>>>>>> some of them even if recently appeared I verified without<BR>my (most)<BR>>>>>> recent changes.<BR>>>>>><BR>>>>>> On Cygwin 1.5, mklib always crashes. I haven't been<BR>able to debug<BR>>>>>> it.<BR>>>>>> This has been over a week.<BR>>>>>> I've had to stop using Cygwin for Modula-3 development<BR>on this<BR>>>>>> machine.<BR>>>>>> I have a good repro but hadn't had luck yet debugging<BR>it.<BR>>>>>> Basically if I shorten the mklib command line (in the<BR>response<BR>>>>>> file) substantially, no crash.<BR>>>>>> There is a cut off somewhere.<BR>>>>>><BR>>>>>> On Cygwin 1.7 machine, stubgen in obliqparse usually but<BR>not always<BR>>>>>>
hangs.<BR>>>>>> It hangs nowhere else.<BR>>>>>> This I verified occured without my recent changes.<BR>>>>>> I only just in the past few days tried Cygwin 1.7.<BR>>>>>> mklib works fine here.<BR>>>>>> Of course since this is somewhat intermittent, maybe it<BR>isn't a new<BR>>>>>> problem.<BR>>>>>><BR>>>>>> I've only tried Cygwin 1.5 and 1.7 on one machine<BR>each, separate<BR>>>>>> machines,<BR>>>>>> though they do coexist ok on one machine.<BR>>>>>> 1.7 seemed much faster (on an unimpressive machine),<BR>though 1.7<BR>>>>>> binares<BR>>>>>> apparently don't run on 1.5 -- at least not if they<BR>use assert().<BR>>>>>> 1.7 is a recent past or future release, a long time in the<BR>works,<BR>>>>>> drops Win9x support, lots of good
sounding changes.<BR>>>>>><BR>>>>>> I should run m3tests more, maybe they will reveal the<BR>crash or the<BR>>>>>> hang as well.<BR>>>>>><BR>>>>>> On LINUXLIBC6 on one machine stubgen was crashing at least<BR>in one<BR>>>>>> directory.<BR>>>>>> But I think this stopped happening.<BR>>>>>><BR>>>>>> Cygwin being broken pushes me to other platforms more,<BR>probably a<BR>>>>>> good thing.<BR>>>>>> I'm loathe to debug the hang. When it occurs I<BR>can't see any stacks<BR>>>>>> in gdb. I can see in strace..<BR>>>>>> I think we are waiting for all the threads to suspend<BR>themselves.<BR>>>>>> I'll probably try moving back to Win32 threads and see<BR>if it clears<BR>>>>>> up.<BR>>>>>> I know that's not
great.<BR>>>>>> There isn't a clear implied question and I know I<BR>should/need to<BR>>>>>> look into these,<BR>>>>>> but I also thought I shouldn't keep this to myself. I<BR>also<BR>>>>>> understand the philosophy<BR>>>>>> of stopping changes when there are problems, to stop<BR>further<BR>>>>>> damage, but, of course,<BR>>>>>> I'm very confident in my changes (always..), have been<BR>testing them<BR>>>>>> on other platforms,<BR>>>>>> and looking them over extra extra since I know of these<BR>other<BR>>>>>> problems.<BR>>>>>><BR>>>>>> I'm not sure any problem on Cygwin is worrisome<BR>really.<BR>>>>>> I think the underlying code is kind of gnarly and I<BR>don't think<BR>>>>>> anyone uses this platform, though people asked for
it.<BR>>>>>> But I did have a crash on LINUXLIBC6.<BR>>>>>><BR>>>>>> - Jay<BR>>>>><BR>></PRE></BLOCKQUOTE></TD></TR></TBODY></TABLE><BR></body>
</html>