OK, it now runs. No more segfaults, no more pseudo-Memory Manager bugs,
and no more inabilities to convert from long to char *.
However, it still does not output correct results. It's time to find some
simple test cases which screw it up. I'm betting I've got some
implementation-defined behavior in there somewhere and Linux does not like
it.
I've already run egcs with -Wall to see if it catches anything... but
alas, it did not.
12:30 PM EDT Hmmm... or maybe just a bug in the text->number
conversion... interesting...
12:38 PM EDT it's not even calling the text->number function...
or at least it seems that way. WTF?! Build with
bison grammar debugger.
12:53 PM EDT gdb was on drugs; it is calling the function. And
there were some bugs in StringToNum...
12:56 PM EDT Then again... maybe it does not call it...
12:58 PM EDT Nope. That was just a minor compile problem; it is
converting "1" to 0... not good.
01:08 PM EDT Found another bug in the number converter, but it's
not the bug. Getting tempting to hit delete and
rewrite from scratch.
01:10 PM EDT Never mind. I think I've got it this time. Running
egcs now (which, btw, on Linux does not hinder my
typing... PMT is SO nice)
01:12 PM EDT Most appear to work, but the timer segfaults. Time to
gdb that core.
01:16 PM EDT Hmmm... var[72]!?!? I don't think so. Probably another
conversion bug. Grrr...
01:22 PM EDT StringToNum needs rewriting; it was the victim of being
written to late at night. Maybe I should just use the
ANSI functions? I'm going to look up sscanf...
01:32 PM EDT atoi should work... but it will fail sometime. Need to
rewrite eventually.
01:45 PM EDT I think it works. But I'll need to send the results back
to the MacSide to compare them. And, BTW, it seems faster
than the MacOS version. (I don't know how to get a high-
resolution timer on Linux). I'm compiling a final,
optimized version with egcs now. I'll then send back
the results and a nice, big, tarball of changed sources
to integrate on the MacSide.
--
