Path: utzoo!censor!geac!torsqnt!jarvis.csri.toronto.edu!cs.utexas.edu!natinst!rpp386!woody
From: woody@rpp386.cactus.org (Woodrow Baker)
Newsgroups: comp.lang.c
Subject: Re: problems/risks due to programming language
Message-ID: <18033@rpp386.cactus.org>
Date: 26 Feb 90 12:49:50 GMT
References: <1597@awdprime.UUCP> <8133@hubcap.clemson.edu> <2903@goanna.oz.au> <2905@goanna.oz.au>
Organization: River Parishes Programming, Plano, TX
Lines: 31

In article <2905@goanna.oz.au>, ok@goanna.oz.au (Richard O'keefe) writes:
> : This argument seems to me about equivalent to saying "One
> : of the debatable features about 'if' is that a new program block is not
> : defined.  That means that you can have a statement which you meant to have
> : in the if statement but isn't."  You know, something like
> :   if (a == b)
> : 	bar(a);
> : 	foo(a);
> :   a++;
> : Do you propose making an editor macro to handle ifs to prevent this?

No:  Fix the compiler to require curly braces around ALL elements of control
structures, whether they are 1 line or not.

> 		case...
> 		    ...
> 			/* now I want to exit the LOOP */
> 				
> (a) can't be done without introducing a goto or return, or rewriting
>     the code.
Wrong.  you can always set a flag within the various cases and test it at
the bottom or top of the loop.  Yes this qualifies as re-writing the code.
But you don't have to use **goto**  (shudder)
Personaly, I feel that curly braces around BOTH parts of if...else...
constructs, and around, while loops, do whiles...case and switch statements
and break statements in cases should be mandantory and enforced as syntax
errors by the compiler if not done.  'C' is just super flexible, but who
needs 6 ways of finding the address of the first element of an array?

Cheers
Woody