return expr and Decus-C
Martin Minow
Previously, on net.lang.c, the following was stated:
1. Decus C does not support "return expression;" where the
expression is not enclosed in parentheses.
2. Decus C predates Kernighan and Ritchie, where the parentheses
were shown as optional.
3. Version 6 Unix C compilers accepted this syntax before
before of Kernighan and Ritchie.
These statements are true. However, Decus C was coded using the
Unix Version 6 reference manual, where the only valid forms for the
return statement were
return
and return ( expression )
Since the person who wrote Decus C did not have access to the
source code for Unix C, he had no way of knowing that the syntax
accepted by the compiler did not agree with the reference manual.
We have not bothered to change Decus C as we feel that we would be
legitimizing a poor programming practice. The change to the compiler,
which is very simple, is left as a exercise for the student.
Martin Minow
decvax!minow
gw...@brl-vgr.uucp
is preferable to
return(expr);
since the latter looks like a function call (which it is not).
Steven M. Haflich
to...@druxm.uucp
By this reasoning, we should use "while expr" instead of "while (expr)",
and "if expr" instead of "if (expr)". And don't forget "switch expr" to
replace "switch (expr)".
My own opinion is that "return (expr)" is clearer, since it clearly
distinguishes between the keyword and the parameter. I think of this as
a general "thing-to-do (thing-to-do-it-with)" syntax that is consistent
among C commands, functions, and macro pseudo-functions.
Tom Laidig
AT&T Information Systems Laboratories, Denver
...!ihnp4!druxm!toml
Joel Coltoff
Do you think that
if expr
looks better than
if(expr)
since that also looks like a function call.
I love to play devils' advocate
--
Joel Coltoff {presby,bpa,psuvax}!burdvax!coltoff
(215)648-7258
Doug Gwyn
( expr )
is also an
expr
which is why
return( expr );
is legal although the definition is
return expr;
However, stylistically I recommend leaving unnecessary parentheses off
the return expr since, as I said, they make it look like a function call.
Both ways are legal and this wouldn't be an important issue except that
some C compilers (apparently the DECUS C compiler) do not accept the
more general form.
Doug Gwyn
while expr
etc. are silly. They are not even legal C.
return expr;
is.
Alan S. Driscoll
> Newsgroups: net.lang.c
> Subject: Re: return expr and Decus-C
Of course the examples aren't legal C, but that's not the
point. The question is, if you are worried that
return (expr);
looks like a function call, why aren't you worried that
while (expr) stat;
also looks like a function call? (Remember that 'stat'
can be the null statement.) Aren't you being just a bit
inconsistent?
--
Alan S. Driscoll
AT&T Bell Laboratories
George Sicherman
"if expr" is impractical.
"return expr" is unambiguous, but how would you parse
if x ++ y;
?
--
Col. G. L. Sicherman
...seismo!rochester!rocksvax!sunybcs!gloria!colonel
ch...@umcp-cs.uucp
If it were a function call, the statement part would be a syntax
error. (Same goes for if(), for(), etc.... Everything except
``return''. [Well, ok, ``do-while''s are a bit funky, but I try
to end them with ``} while (expr);''.])
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci (301) 454-7690
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@maryland
Alan S. Driscoll
>From: ch...@umcp-cs.UUCP
>Newsgroups: net.lang.c
>Subject: Re: return expr and Decus-C
>Posted: Sun May 13 21:47:44 1984
>Who says ``while (expr) statement;'' looks like a function call?
>If it were a function call, the statement part would be a syntax
>error.
You are forgetting that the body of a while statement may be empty.
Doug Gwyn
if ( cond ) stmt
or
while ( cond ) stmt
It DOES give me the choice of whether to write
return expr;
or
return( expr );
Given the choice, I vote against the redundant parentheses. If the
rest of the language syntax were more like Algol-68 or Djikstra's
then I would be happier, but short of using Bourne's macros I have
no choice about that.
C definitely overworks its special characters and keywords, and
this adversely affects readability.
(Nevertheless I would rather use C than any of the major contenders,
but within its syntax one should still adopt as readable a style as the
language permits.)
Example #22
Keywords like if, while, and switch (which use parentheses for their
arguments) have already been mentioned as non-functions that use parentheses.
I like the parentheses, and if anyone wishes to avoid confusion between func-
tions and keywords-with-parentheses, just use some whitespace!
For example:
function(arg1,arg2)
keyword (arg1,arg2)
or, if you prefer,
function( arg1 , arg2 )
keyword ( arg1 , arg2 )
The idea is that the function is "connected" to the parentheses.
<_Jym_>
: Jym Dyer : Nashua, NH : ...{allegra,decvax,ucbvax}!decwrl!rhea!vaxuum!dyer :
ShanklandJA
If one is serious about changing if & when syntax to remove ( ),
then something else must also be changed to indicate grouping.
The usual solution is something like
if cond then stmt fi
where if, then, & fi are keywords.
Far be it from me to intrude on the original discussion about whether
"return(expr)" is better than "return expr" or vice versa (though my
stomach just rumbled something that sounded suspiciously like
"who cares?").
But Doug's statement above sure looks wrong to me.
Looks to me as though the 'if' and 'then' keywords already bracket
the condition, and the presence or absence of a 'fi' in the language
has nothing to do with whether or not the language requires the
condition to be parenthesized. Keywords like 'fi' end up in languages
to get rid of the "which if does this else belong to" confusion, as in:
/* BEFORE: */
if a then
if b then
c
else d /* indentation is misleading, "else d" goes with "if b" */
/* AFTER: */
if a then
if b then
c
fi
else d
fi /* fee, fi, fo, fawn, ambiguity is gone! */
Jim Shankland
..!ihnp4!druxy!opus
ch...@umcp-cs.uucp
right too: in most cases,
<insert arbitrary function name> (expr) <statement> ;
would be a syntax error. Besides, I try to keep all my "while"s
with null statements as
while (expr)
;
(By the way, does anyone have an option for the "indent" program
that comes with Gosling Emacs, to make it not put null statement
";"s right up against the close parenthesis?)
a...@hpfcla.uucp
> is preferable to
> return(expr);
> since the latter looks like a function call (which it is not).
Unless, of course, expr is more complicated than the null string, in which
case parentheses are a very nice way to set it apart. But seriously...
RETURN(3) Parody Systems RETURN(3)
NAME
return -- return from C procedure call
SYNOPSIS
void return (value)
anytype value;
DESCRIPTION
This procedure never returns to the caller. Instead, it
casts the given value to the procedure type of the calling
procedure, without loss of size or accuracy. Then it causes
the user program to continue immediately after the place
where the calling procedure was itself called. The calling
procedure appears to return value to its caller as a
constant of the proper type, should the caller care to use it
in an expression (including a simple assignment).
The value parameter is optional and may be omitted.
If a procedure ends without calling return() first, the
operating system calls it for you with no parameters.
SEE ALSO
setjmp(3)
BUGS
Due to a bug in the compiler, this procedure can be called
without placing parentheses around its parameter.
Sam Kendall
about? How about ... runtime checking? Or static checking? Or
radical optimization? Has anyone made a compiler (or preprocessor)
which will substitute an instruction (or asm statement) for a strcpy,
say?
Sam Kendall {allegra,ihnp4,ima,amd70}!wjh12!kendall
Delft Consulting Corp. decvax!genrad!wjh12!kendall
Dick Dunn
>> is preferable to
>> return(expr);
>> since the latter looks like a function call (which it is not).
>
>By this reasoning, we should use "while expr" instead of "while (expr)",
>and "if expr" instead of "if (expr)". And don't forget "switch expr" to
>replace "switch (expr)".
Seems like a good idea to me. (Put down that torch! Not for C, but for
another language.) After all, Pascal manages without the parens around the
expr's in "if", "while", and "case" (Pascal analog of "switch"). Of
course, some Pascalers are amazed that C doesn't have "then" to go with
"if".
(It's a little trickier to get rid of BOTH the parens around the expr in
the "if" AND the "then" keyword - but it's possible. Look at the way Icon
handles comparable situations.)
--
...A friend of the devil is a friend of mine. Dick Dunn
{hao,ucbvax,allegra}!nbires!rcd (303) 444-5710 x3086
hami...@uiucuxc.uucp
uiucuxc!hamilton May 16 14:39:00 1984
i prefer
return (expr);
why shouldn't a function un-call resemble a function call? i've never
gone hunting for a function named "return" by mistake.
Guy Harris
> about?
Hell, yes. *Anything* would be more interesting to talk about than
religious arguments about the "right" place to put tokens on "paper".
I've seen a wide variety of styles, and most of them are readable.
Only those that aren't readable (i.e., crappy indentation) are deserving
of censure (or even discussion).
> How about ... runtime checking? Or static checking? Or
> radical optimization? Has anyone made a compiler (or preprocessor)
> which will substitute an instruction (or asm statement) for a strcpy,
> say?
Well, you guys wrote a compiler that does the first and/or the second, so
the ball is in your court.... By "radical optimization", do you mean what
a "typical" optimizing compiler does, or something beyond that? Yes, I
hear some of you out there complaining that you can't write device drivers
for an optimizing compiler. Well, the problem is that some variables'
behavior can't be determined by dataflow analysis; variables shared between
processes (either in the kernel or in shared segments - as of S5, UNIX actually
has an official implementation of shared data!) have the same problem as
device registers, which are "variables" shared by the CPU and the device.
PL/I had a simple solution; declare the variable "abnormal". This tells the
compiler that if the variable gets set to "77" in statement N, that the
variable may not have the value "77" in statement N+1.
As for the substitution of instructions for subroutine calls, this is done
more and more with the aid of "sed" scripts; both Bell and Berkeley's
recent distributions do it quite a bit. They also do substitutions of "text"
for "data" in the assembly output, to move common read-only data like strings
to shared code space. This crock, at least, may become obsolete soon with
a "const" or "readonly" storage class. It would be nice if the "asm.sed"s
could also be made obsolete. Two ways I can think of off the top of my head
are:
1) tweaking the peephole/final optimizer (C2) to detect certain
subroutine calls and to substitute assembly code sequences. The
simple-minded way is to leave the pushes of the operands there, and
to have the instruction take its operands off the stack. A fancier
way might turn
movl #count,-(sp)
movl $to,-(sp)
movl $from,-(sp)
calls #3,_bcopy
into
movc3 from,to,#count # or whatever the VAX-11 syntax is
which would be trickier.
2) having a way to specify to the code generator that certain
"subroutines" are really builtins, and have it generate the
appropriate instruction. Of course, one would want to be able to
shut this off, as you might have a routine called "bcopy" which
*didn't* copy arg[3] bytes from arg[1] to arg[2] and not want all
calls to that routine turned into block moves.
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guy
ha...@log-hb.uucp
radical optimization? Has anyone made a compiler (or preprocessor)
which will substitute an instruction (or asm statement) for a strcpy,
say?
Sam Kendall {allegra,ihnp4,ima,amd70}!wjh12!kendall
Delft Consulting Corp. decvax!genrad!wjh12!kendall
--
{decvax,philabs}!mcvax!enea!log-hb!hans
Hans Albertsson,
TeleLOGIC AB
Box 1001,
S-14901 Nynashamn,
SWEDEN
j...@ism780.uucp
ism780!jim May 16 19:00:00 1984
> >Who says ``while (expr) statement;'' looks like a function call?
> >If it were a function call, the statement part would be a syntax
> >error.
>
> You are forgetting that the body of a while statement may be empty.
Some people can't tell the difference between a discussion and a debating
club. Please restrict this sort of irrelevant drivel to net.politics.
-- Jim Balter, INTERACTIVE Systems (ima!jim)
ha...@log-hb.uucp
Terribly sorry, but there were at least 3 spurious
followups leaving this site a few days ago, on
May 17, to be exact, all due to a faulty news-reading program.
They all consisted of:
A) A header indicating that it came from me.
B) The complete body of a message I had just finished reading.
C) The original signature.
D) My signature.
It wasn't me trying to steal other peoples views outright,
just good old " Manual? Reading? Why?" syndrome....
Sorry if my incompetence disturbed anyone.
Dick Dunn
>> about?
>
>Hell, yes. *Anything* would be more interesting to talk about than
>religious arguments about the "right" place to put tokens on "paper".
Agree also - but here's a meta-point: The fascination with "where to put
the tokens on paper" has flooded another medium in the past - good old
SIGPLAN Notices. The editor (Richard Wexelblat, out there somewhere) made
an exception to the general rule of printing anything which is civil and
relevant - in January 84 he announced that he would print no more articles
on prettyprinting. What had happened (my personal viewpoint) is that
people had started using SIGPLAN as a means to get something in print - and
you can almost always find some reason to disagree with someone else's
conventions. We saw a flood of articles on how to format (mostly Pascal
and Pascal-like-language) programs, most of which were crap that reduced to
"My way is better because I like it so I do it my way." The most amazing
fact about the whole thing was not Wexelblat's action but the fact that
there wasn't a flood of letters saying "let's cut the crap and get back to
real work."