[comp.lang.c] Turbo C Problems

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