<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>No need for a change in platform-independent code now.<BR>
My question was sort of "can anyone else try this out, I'm lazy".<BR>
But I looked up the definition of dup/dup2 and decided Cygwin wasn't doing anything wrong, looked at the strace, saw we were closing 0, started some RTIO... and if IsDebuggerPresent, DebugBreak and finally realized of course what was happening. (the debugging options are really not good. I couldn't even see the globals in gdb, neither of the obvious names worked...I was doing a little debugging in cdb as well and found a crashing bug in it, very very very unusual)<BR>
<BR>
Writing a struct checker should actually be pretty easy.<BR>
The trick is probably mainly to limit the dependencies so it can work when much of the system is broken, or to use a cross strategy if possible..it helps that NT386 supports two sort of platforms/targets/configurations, so you can cross with a smaller context switch. :)<BR>
<BR>
I'm not sure how to get field offsets in Modula-3 but if you get as far as having the compiler working, it can generate C with assertions as to sizes and offsets.<BR>
<BR>
The compiler's dependency on stat is "the problem".<BR>
<BR>
Again I like that idea of wrapping C in C, to expose a portable interface.<BR>Of course, it's inefficient. The direct exporting of C interfaces, when they are /correct/ is pretty efficient.<BR>
<BR>
NT386GNU should be just about "self hosting" now -- able to build a "min" distribution and then "upgrade".<BR>
Small hacks in pylib.py needed that might break Win32, no big deal, it's "just the scripts". :)<BR>
Next steps will be:<BR>
a) consider changing the "naming conventions" <BR>
it's still foo.lib and not foo.a, foo.dll and not foo.so.<BR>
b) see if X Windows works (stuff builds) <BR>
c) the small set and bitmap bugs (running the tests!) <BR>
<BR>
I do have one more commit to enable stuff, a small one, where the Slash is determine at runtime in <EM>slightly</EM> more code.<BR>
SL is already determined at runtime, but M3Path maps naming convensions (foo.lib vs. libfoo.a, foo.dll vs. foo.so) to also determine slashes. It might even work if they were escaped, but what I have is a good solution.<BR>
<BR>
(if I figure I can ramble here, since I'm on topic. :) )<BR>
<BR>
- Jay<BR><BR><BR>
<HR id=stopSpelling>
<BR>
> Date: Sun, 17 Feb 2008 10:30:01 +0100<BR>> From: wagner@elegosoft.com<BR>> To: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] NT386GNU status/fishing for guesses..<BR>> <BR>> Quoting Jay <jayk123@hotmail.com>:<BR>> <BR>> > Nevermind, of course, I should have known, even though I'm working <BR>> > on fixing the stat struct (probably to blame for files always being <BR>> > out of date) and thought I might have it right, I should have known, <BR>> > I have it too small and the next variable is getting overwritten, <BR>> > causing us to close(0)..<BR>> <BR>> Yes, the C interfaces are the place where ports are most likely to<BR>> be broken. There are no checks there; it's completely unsafe.<BR>> I wonder if one could write a checker that compares the sizes of<BR>> the most important structures in C and M3, but that would probably<BR>> not be trivial.<BR>> <BR>> > If I put in arbitrary large padding at the end, it grows enough to <BR>> > cover up the problem..now to get it right..<BR>> > null_fd and the entire struct stat need not be globals, just the dev <BR>> > field...of course optimize that and I would have a stack corruption <BR>> > instead, not sure it would have been harder or easier to figure <BR>> > out..I should have started at the bottom of the system and gotten <BR>> > all the headers right in the first place....sigh.<BR>> <BR>> Yes, it's always a good idea to get the base right at the start.<BR>> On the other hand, you will usually return there during ant porting,<BR>> regardless of your best efforts ;-)<BR>> <BR>> > VAR null_done := FALSE; null_stat: Ustat.struct_stat; null_fd: INTEGER;<BR>> ><BR>> > PROCEDURE IsDevNull(READONLY statbuf: Ustat.struct_stat): BOOLEAN <BR>> > RAISES {} = VAR result: INTEGER; BEGIN IF NOT null_done THEN <BR>> > null_done := TRUE; null_fd := Unix.open( <BR>> > M3toC.FlatTtoS("/dev/null"), Unix.O_RDONLY, Unix.Mrwrwrw); IF <BR>> > null_fd < 0 THEN RETURN FALSE END; RTIO.PutText("1 null_fd is " <BR>> > & Fmt.Int(null_fd) & "\n"); 3 result := Ustat.fstat(null_fd, <BR>> > ADR(null_stat)); RTIO.PutText("2 null_fd is " & <BR>> > Fmt.Int(null_fd) & "\n"); 0 EVAL Unix.close(null_fd); <BR>> > and then close 0 here oops IF result # 0 THEN null_fd := -1 END<BR>> <BR>> [Could you try to persuade your mailer to produce a readable text<BR>> form besides HTML? If not it looks like that :-(]<BR>> <BR>> Anyway, as your previous posting asked about a change in general POSIX<BR>> support files, I'd really advise you to try out such changes on at<BR>> least one other platform (e.g. Linux), however innocuous they may seem.<BR>> <BR>> Thanks for all the work,<BR>> <BR>> Olaf<BR>> -- <BR>> Olaf Wagner -- elego Software Solutions GmbH<BR>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<BR>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<BR>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin<BR>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR>> <BR><BR><br /><hr />Need to know the score, the latest news, or you need your Hotmail®-get your "fix". <a href='http://www.msnmobilefix.com/Default.aspx' target='_new'>Check it out.</a></body>
</html>