#Works on IBM, not on Ami
7 messages in this thread
Scott,
Just because something works on a 16-bit Intel architecture correctly
does not mean that the code is written correctly in a machine-independent
manor. It is even possible that there could be a real bug in Turbo C that
would let things work properly for you, though that isn't as likely. Your
test for a working program is not foolproof by any means.
— Mike Roth
To add to that, position-dependent bugs like array-overwrites and
uninitialized pointers show that kind of behavior. I've personally talked
to many people saying "But it worked on compiler 'x' but not on Aztec C",
only to discover that half of the pointers used in the program were never
initialized anywhere…
-Mike
I definitely agree. I saw a program which worked under Lattice but not
under MicroSoft C. It turned out that the stack was getting overwritten
and the two compilers allocate local variables on the stack in reverse
order. This changed which variables got trashed.
— Mike Roth
But the problem on the Lattice compiler is that a switch statement that
works fine on the IBM is not working when compiled by Lattice. It is a
switch with seven cases, some of which in tern have switch statements
nested inside of them. What happens is that when the main menu comes up
and you input a choice the switch statemente switches on the unsigned int
variable that holds this choice. But on the Lattice compiled version, when
you input something at the prompt and hit return it goes to an empty line
but if you then type another letter after this on the empty line it will go
back to the main menu. (Weird Huh?) (and yes the switch statement
contains a default: and no, I didn't use getchar, I used scanf because I
know getchar doesn't work for shit on the amiga. So there.
With a big top that! <hehehe> 🙂
Scott
Again, the fact that it works with a PC compiler means not alot. All it
takes is a single uninitialized pointer, which just happens to point to
your switch code on the Lattice compiled version. Write to that pointer,
and <poof> – instant code-mush.
The moral of the story is, without seeing the _exact_ code, in context, its
pretty much impossible to figure out whether its the compiler or the
programmer at fault.
-Mike
Mike,
You forget one thing, this is the main menu, and in my program
nothing is done before the main menu is displayed, therefore, it cannot be
me writing to the pointer.
Scott
Well, its tough to comment without seeing the code. However, it only takes
a single tiny call to strcpy() before the main menu code for you to crash
and burn.
-Mike