Turbo Trouble

[Marshall Cline]

In article <1159 at draken.nada.kth.se> d88-jwa at nada.kth.se (Jon W{tte) writes:

>Summary: Turbo C 2.0 hangs on me !
>I recently ran into a problem (bug ?) in Turbo C 2.0 using #define:
>#define SetRect(rectp, t, l, b, r)\
>(rectp)->top = t, (rectp)->left = l, (rectp)->bottom = b, (rectp)->right = r

NOTE FOR ALL MACRO-USERS:  You really must be careful about how you use the
formal parameters inside macros.  In particular, each "t", "l", "b" and "r"
in the above "#define" should be parenthesized.  Ie: Change it to:
#define SetRect(rectp, t, l, b, r)\
 (rectp)->top=(t), (rectp)->left=(l), (rectp)->bottom=(b), (rectp)->right=(r)
              ^^^                ^^^                  ^^^                 ^^^
PERSONAL_OPINION_BEGINS {
	flame_thrower = OFF;
	As a statement of style, I tend to over-parenthesize assignments and
	comma-exprs.  Ex: My tendancy is to say: "(foo=bar),(baz=barf)" to
	emphasize the order.  The other (personal preference) way is with
	a "do {...} while (0)" statement, as in:
#	define SetRect(rectp, t, l, b, r)	\
		do {	(rectp)->top = (t);	\
			(rectp)->left = (l);	\
			(rectp)->bottom = (b);	\
			(rectp)->right = (r);	\
		} while (0)
} /* PERSONAL OPINION ENDS */

>This macro later gets called by:
>[definitions, among them struct rect { int left, top .......]
>        rect r;
>        SetRect(&r, 20, 20, 200, 400);
>This should be fairly legal. I tried to compile it, and my machine
>(Victor V286A with 640 kBytes RAM) hung on me:
>Internal Stack Overflow -- System halted

I had a problem with some Turbo-C code similar to this.  Borland has
the cpp pass "built-in" to the compiler itself (for speed purposes, I'm
sure).  Anyway, "cpp" expands your macro out to a long line of macro-less
code.  This long line is then re-parsed as C code.  The problem I had
disappeared when I made the macros shorter.

I suspect the Turbo-C compiler uses something like "gets()" rather than
"fgets()" to snatch up the long lines.  Either than or it simply overruns
a buffer somewhere.  In any event, when I replaced macros with either
shorter macros or function calls, the problem vanished.  (I had macros
inside macros inside macros -- a mess).

The point is that the _SAME_EXACT_ code ran PERFECTLY on our Un*x boxes,
but failed miserably under Turbo-C.  The errors generated were really
wierd too.  Like a divide by zero runtime error occuring in a "x = 1;"
Twilight zone stuff.

Cheers.
Marshall
--
	________________________________________________________________
	Marshall P. Cline	ARPA:	cline at sun.soe.clarkson.edu
	ECE Department		UseNet:	uunet!sun.soe.clarkson.edu!cline
	Clarkson University	BitNet:	BH0W at CLUTX
	Potsdam, NY  13676	AT&T:	(315) 268-6591