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: [EMAIL PROTECTED]
| > To: [EMAIL PROTECTED]
| > 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 = [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Institute or [EMAIL PROTECTED]
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
