Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!batcomputer!sun.soe.clarkson.edu!cline
From: cline@sun.soe.clarkson.edu (Marshall Cline)
Newsgroups: comp.lang.c
Subject: Re: Turbo Trouble
Message-ID: <CLINE.89Jun7152959@sun.soe.clarkson.edu>
Date: 7 Jun 89 19:29:59 GMT
References: <1159@draken.nada.kth.se>
Sender: news@sun.soe.clarkson.edu
Reply-To: cline@sun.soe.clarkson.edu (Marshall Cline)
Organization: Clarkson University, Postdam NY
Lines: 60
In-reply-to: d88-jwa@nada.kth.se's message of 3 Jun 89 09:38:15 GMT

In article <1159@draken.nada.kth.se> d88-jwa@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@sun.soe.clarkson.edu
	ECE Department		UseNet:	uunet!sun.soe.clarkson.edu!cline
	Clarkson University	BitNet:	BH0W@CLUTX
	Potsdam, NY  13676	AT&T:	(315) 268-6591