<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">The problem is not your changes, the problem is that putting C code can't be checked by a type safe checking process: I do agree the goodness of your checks, which may get things better, but unfortunately you have seen the effects of the this changes, we can't have human checking to solve unhidden bugs.<br>Compile type checking allows to discard problems in Modula-3 code and at least a clue that something needs more checking in UNSAFE Modules or Interfaces.<br>You have changed that we depend no more on cloned platform dependent .i3 files, but on C code which it slef depends on unsafe C platform dependent thirdparty libraries. That is the problem is not now on the Modula-3 source code but in the actual platform. I can't agree that is safer than it was before, nor because of the language, or you, but of the thid party code. Now we have more code just that
it's no more Modula-3, it's C but yes, is lesser code (well forgeting about C preprocessor). <br><br>I hope this is more clear of my ideas and any clue of what i am tryin to say here.<br><br>Thanks for your comments.<br><br>--- El <b>lun, 16/3/09, Jay <i><jay.krell@cornell.edu></i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">De: Jay <jay.krell@cornell.edu><br>Asunto: RE: [M3devel] recent problems?<br>Para: "Daniel (M3)" <dabenavidesd@yahoo.es>, "Tony" <hosking@cs.purdue.edu><br>CC: "m3devel" <m3devel@elegosoft.com><br>Fecha: lunes, 16 marzo, 2009 9:47<br><br><div id="yiv878206134">
<style>
#yiv878206134 .hmmessage P
{
margin:0px;padding:0px;}
#yiv878206134 {
font-size:10pt;font-family:Verdana;}
</style>
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 border="0" cellpadding="0" cellspacing="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:<br> 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:<br> 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<br> 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<br> ../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>>>><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:<br> 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<br> 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>>>>>><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<br> 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<br> 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<br> it.<br>>>>>> But I did have a crash on
LINUXLIBC6.<br>>>>>><br>>>>>> - Jay<br>>>>><br>></pre></blockquote></td></tr></tbody></table><br>
</div></blockquote></td></tr></table><br>