dalegass@dalcsug.UUCP (Dale Gass) (08/22/87)
I've been having some real problems with Turbo C lately. It seems that it really screws up stack-wise in several situations. Here are some of the ways I've found this occurs... #pragma inline, occuring in a module which is compiled in the integrated environment (i.e. no machine code) causes problems. I realize this is not needed (allowed) in the integrated environment, but at least it could give an error rather than screw up the stack. The results of doing this led to the following: The return statement of a function which used stack registers (and thus PUSHed SI and DI) borrowed (jumped to) the RET of a function which didn't use stack registers. Ugh! Another time it jumped to the start of the function, rather than returning. Very strange. Another situation which can cause problems (unrelated the the #pragma problem) seems to be the optimization applied to the inportb() and outportb() functions when #include <dos.h> is used. Look at the code generated by the following C source: { outportb(port,inportb(port) & mask) } <-- An extra PUSH DX is put in the middle of it, which royally screws the return. Another time the stack got messed was during a fancy shift operation with far pointers. Don't remember the exact statement. I believe the part that seemed to mess it up was ORing an 'int' with a 'char' (which should have automatically been casted). If I put the manual (int) cast in for the char, all works well. I'm doing a lot of low level work interfacing with Turbo C, and it's bad enough debugging my own stack problems, without having to babysit Turbo C's code. I find the general level of code generation to be very poor. Sequences such as MOV [memory],AX MOV AX,[memory] are not uncommon. You don't see or expect this except in $30 Mickey Mouse compilers. I'm looking forward to Turbo C V2.0. -dalegass@dalcs.uucp