[OpenAFS-devel] Fwd: [patch review] libafs solaris cleanup

[Garance A Drosihn]

At 7:55 PM -0500 2/13/07, Marcus Watts wrote:
>Garance Alistair Drosehn writes:
>...
>  > For what it's worth, sometime in my early freebsd days it was
>>  explained to me that 'return (blah)' is preferred simply because
>>  it makes it easy to replace 'return' with a #define'd macro, if
>  > you needed to do that for some debugging reason.
>>
>
>Ok, sure, for some sufficiently simple program
>	#define bug(x) printf ("__FILE__:__LINE__ return %#lx\n",(x)),(x)
>	main(){
>		return (5);
>	}
>you could compile it with
>	cc -Dreturn=bug
>or with just cc
>
>I don't think anybody is ever going to do anything remotely
>like this with openafs.

I have done things like this with packages just as nasty and
low-level as openafs.  I have not used 'printf' statements, of
course, but I have done things like adding assert-like statements.
"if our global pointer is zero right now, then come to a screeching
halt!".  Or I stuff away some value in a global variable, which I
can go back and look at later on.  I know I've done this when
debugging things in samba, and it's hard for me to imagine why
such a trick would *never* be useful to do in openafs.

Note that I don't mean to be arguing that openafs must include
commas on return statements.  I'm just passing along what I was
told back when I asked about them in the style(9) guidelines used
by FreeBSD.

>Just for starters, you'd have to rely
>on return falling off the end of the function and returning the
>last expression evaluated.

I'm not sure what you're saying here.  Why would a return statement
fall off the end of a function?  What does that even mean?  It is
possible you could get to the end of a function without hitting
an explicit 'return someval;' statement, but don't most compilers
already warn you about that anyway?  Yes, you can ignore the
warning and then this trick with redefining 'return()' would not
be reliable -- but at least you were warned that it wouldn't work.

>I've always thought that return() was leftover from b or bcpl
>syntax.  In bcpl it's "RESULTIS" - no () required.  Looks like b
>requires () though, so I think that's the origin of this convention.

For what it's worth, here is an excerpt from some message sent to a
freebsd mailing list back in 2001:

  |  I asked Dennis Ritchie about this some time back.
  |  Here's the reply:
  | 
  |  > Date: Fri, 11 Feb 2000 01:36:53 -0500
  |  > From: dmr@plan9.bell-labs.com
  |  > To: grog@lemis.com
  |  > Subject: Re: 'return expression' or 'return (expression)'?
  |  >
  |  >> I've been wondering about the tradition of writing 'return
  |  >> (expression)' instead of 'return expression' in C code.  The
  |  >> earliest documentation I have (K&R I) suggests I use the former
  |  >> (page 68), without specifying why, while appendix A (page 218)
  |  >> specifies 'return expression'.
  |  >
  |  >> I got hold of last1120 and compiled and ran it against a test
  |  >> program, and it seems that this version won't accept the syntax
  |  >> 'return expression': the parentheses are mandatory.  Would it
  |  >> be fair to consider the usage 'return (expression)' as an
  |  >> archaism?
  |  >
  |  > An archaism: just so.  The language and compiler ca. 1973 did
  |  > want the parens.  By the 5th edition (1975) I had realized that
  |  > they weren't needed and the syntax was just 'return expression'.
  |  >
  |  > On the other hand, no one seemed to want to make use of the new
  |  > freedom.  I glanced at v7 source (1977) and couldn't find any
  |  > instances of non-parenthesized return values-- I might have
  |  > missed an instance, but there couldn't have been more than a
  |  > very few. Evidently it had become wired into the mental syntax.
  |  >
  |  > This was certainly true for Brian in K&R 1 and evidently
  |  > for me as well, since the very few examples in the appendix
  |  > use the ().  But the grammar does indeed reflect the fact
  |  > that they weren't required.
  |  >
  |  >        Dennis

As for me (garance), I didn't write any programs in C until the late
1980's, so I am too much of a newbee to comment on the language.  :-)

-- 
Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
Senior Systems Programmer           or  gad@freebsd.org
Rensselaer Polytechnic Institute    or  drosih@rpi.edu