Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uwm.edu!linac!att!cbnews!cbnewsl!marks
From: marks@cbnewsl.att.com (mark.e.smith)
Newsgroups: comp.lang.c
Subject: Re: Unnecessary parentheses (Was: Help: VAX C problem)
Message-ID: <1991Apr22.031525.4070@cbnewsl.att.com>
Date: 22 Apr 91 03:15:25 GMT
References: <3176@oucsace.cs.OHIOU.EDU> <4329.280f017f@iccgcc.decnet.ab.com> <4003@bruce.cs.monash.OZ.AU>
Organization: AT&T Bell Laboratories
Lines: 35

In article <4003@bruce.cs.monash.OZ.AU> mmcg@bruce.cs.monash.OZ.AU (Mike McGaughey) writes:
>browns@iccgcc.decnet.ab.com (Stan Brown) writes:
>
>>In article <3176@oucsace.cs.OHIOU.EDU>, sadkins@oucsace.cs.OHIOU.EDU (Scott W. Adkins) writes:
>>> When I learned C, I was taught that parens were unecessary, but it was 
>>> highly recommended to use them for the same reason parens were to be used
>>> with macros (i.e. #define).  I have used them ever since and have grown 
>>> quite attached to them.  Anymore, the program just would not look right
>>> if I leave the parens out.  Oh well :-)
>
>>I'm afraid I don't see the analogy.  
>
>Oh, the point is just that if you stick to
>
>    return(val)
>
>it makes it much simpler to #define return to be a macro, if you should
>ever have to do so (for instance, in printing a trace).  Not that
>that's terribly useful, with a decent debugger.
>
>Mike McGaughey			AARNET:	mmcg@bruce.cs.monash.oz.au

'return' isn't a function, so it makes sense not to use it as such.

However, I have upon occasion used a function 
	Return( ret_val )

where Return() is a macro that restores scope.  This can be
used as a makeshift malloc()-free() monitor, complete with lovely setjmp()-
longjmp()s.  (The setjmp() and longjmp()s are also hidden in macros.
In for a penny...)

Now if we could only get the *language* to do this for us!

Mark Smith