Path: chuka.playstation.co.uk!news
From: Majik <majik@127.0.0.1>
Newsgroups: scee.yaroze.freetalk.english
Subject: Re: ANSI C code
Date: Wed, 11 Mar 1998 17:41:58 +0000
Organization: PlayStation Net Yaroze (SCEE)
Lines: 76
Message-ID: <3506CCE6.7301@127.0.0.1>
References: <6e5qdr$p7b1@emeka.playstation.co.uk> <6e693k$6nq4@chuka.playstation.co.uk>
NNTP-Posting-Host: darkstar.stnc.co.uk
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.0 (WinNT; I)

JohnT wrote:
> if(expression)
> {
> // code here
> };
> 
> or
> 
> for(expression)
> {
> // Code here
> };
> 
> Both are technically wrong as all closing braces ( } ) should not have a
> semicolon after them.
;)
I don't think it is technically wrong, all that is being done is that a
null
statement is added after the braces, and this is syntactically okay.

> Some compilers let this slip whilst others are strict
> about it.
a working compiler won't complain.. you may get a warning, as the empty
statement
could be generated by a duff macro:

#define POP(x)

if(this)
{
// blah
}
POP(that);

will produce the same stuff

if a compiler refuses to compile your code because of a semicolon after
a closing brace then it is at fault.

So while being technically correct, I admit it does look odd, silly even
and I also suggest getting out of the habit, because you never know when
a compiler
will start complaining...

:)

PS, I get to play with broken compilers for a living, you wouldn't
believe how bad they can get... off topic consider this

void foo(void)
{
	int x, y, tmp;

	// some code

	tmp = x;
	x = y;
	y = tmp;

	// more stuff
}

I've had compilers _optimise_ out the variable 'tmp' before :$ so it
didn't do what it was supposed to.

;)

Majik.



--
-- Majik - Owner/Curator of the Sinclair Microcomputer Museum
-- 	Spod in a suitcase - ' Have Compiler, will travel '
-- 		http://mudhole.spodnet.uk.com/~majik/
--