jafischer@watrose.UUCP (01/30/87)
>Grovel, grovel, abase, abase, repent...<
*Ahem* Referring to those Megamax "bugs" I mentioned
previously: I have come up with a new maxim, namely "A self-
taught programmer is a dangerous one." Now I'm not exactly self-
taught, but I am as far as C goes. U of Waterloo doesn't teach C
until some third year courses in which you're (naturally) expected
toi pick it up on your own. I've even done about 5000 lines of C
programming on my work terms, but heck, after realizing that each
of the "bugs" I mentioned were really quirks of the language that
I should be aware of, well... I'm more than a tad embarassed. And
I deserve to be flame-broiled to death, since I really acted with-
out thinking of the responsibility of posting a supposed bug no-
tice to the Net, especially for such a popular product.
The (++) problem:
for (loop = 0; loop <= whatever;
printf("%d %d\n", something[loop], other[loop++]))
;
This will print out 'something[loop+1]' and 'other[loop]'
on each line. I.e.:
something[1] other[0]
something[2] other[1]
...
To me, this looked like Megamax was doing something odd with the
(++) operation. However, because of the order of arguments on the
stack, the third argument is being pushed on the stack before the
second, and hence the '++' takes effect before the second argument
is processed. I just figured this out last night as I was about
to post something saying "look, here's that compiler error I
mentioned..." I guess this doesn't classify as a compiler error,
does it? It sure seems to be against intuitive reasoning, and the
look and feel of the statement. When looking at that statement, I
assume, in my conditioned left-to-right way of looking at things,
that the argument to the left should be evaluated before the
argument to the right, just like in an expression the terms are
normally evaluated left-to-right. I'll have to watch out for
this, since it will probably happen with any ST compiler.
(My "C Programmer's Handbook" states that "the order in which
the argument expressions are evaluated is not [<--italics]
guaranteed." Oh.)
The (%) problem:
Nuts. I can't find it. I have a feeling that it was an
expression something like "Random() % 8", being passed as an
int parameter, and I should have typecast it into (int)Random() %
8. Something like that.
Well. I've certainly learned my lesson. I should have
posted the original "bug notice" as a "Gee, I'm getting these
results with this and that C statement... Is there something I'm
doing wrong?" I guess I was too eager to be the hotshot who found
some drastic bugs in Megamax... *sigh* I'm going to bed. To all
of the hundreds or thousands of people in front of whom I've just
humiliated myself: please accept my apologies.
Just because I've made a fool of myself once, though, don't
discount my previous flame of Ms.EM. I even downloaded the
MSPATCH.PRG that was posted to Compuserve. No go. I also tried
everything with 'interrupts' on and off (it gives you that option
at boot time), and _nothing_ I tried (i.e., Lotus, Dbase III,
Wordstar, Norton Utilities, (even CHKDSK.COM!), and a dozen
others) would run. If we get the 5 1/4" drives in, I'll post some
results. Looks like we have to wait for Atari's hardware
emulator. Has _anyone_ out there had any luck using DOS 3.2 and
the internal ST drives? Is there _something_ else that the user
must do before things will run? I've always done it from a cold
boot, so there weren't any strange accessories or TSR programs in
the way. I tried the "flip keyboard" or whatever option. It does
execute all the built-in DOS CLI commands, like 'dir' and 'cd' and
others. But I simply could not get one single program to load and
run.
--
- Jonathan Fischer (jafischer@watrose)
or: watmath!watrose!jafischer
or: jafischer%watrose@waterloo.csnet
or: jafischer%watrose@waterloo.csnet@csnet-relay.arpa