Using "return" with parantheses?

[Joona I Palaste]

You missed one too ;-)

((printf)(("%d\n"), (a)));

Good catch!

 

[Fao, Sean]

Good catch!

Wow you're fast! I just sent that like 10 seconds ago!

 

[Giorgio Pastore]

You missed one too ;-)

((printf)(("%d\n"), (a)));

Uhm. One more level of parenthesis and your C code could be compiled by
a lisp compiler

 

[Dan Pop]

The syntax of if, for, and while, to name a few, C statements, requires
parenthesis and I don't think it makes them look like functions.

That's because something else is *usually* following the right
parenthesis. And even when there is nothing else, many people prefer
to write the semicolon on a separate line.

Dan

 

[Dan Pop]

As for typing "return (0);" being typoed "reutrn (0);" and not being
caught, then..

1. Every viewer/editor[1] I use for C has syntax highlighting that show the
return as obviously wrong.
2. I've always used a compiler that warns when you use a non-prototyped
function.

Some day, you may be forced to use a less friendly set of tools (some
people have provided real life examples in this newsgroup). The less
your coding style relies on tools, the more robust it is and it is a fact
that "reutrn 0;" requires a diagnostic, while "reutrn (0);" doesn't (in
C89). All other things being equal, it is downright foolish to ignore
such arguments.

Dan

 

[Dan Pop]

When I first started programming in C, I was asked to write a macro, which
would calculate the number of elements in an array, but couldn't use any
functions. I knew I could do it like this:

#define NUM_ELTS(x) (sizeof(x) / sizeof(x[0]))

However, at the time, the parentheses that I was taught to use made me think
that sizeof was a function.

I would write that as

#define NUM_ELTS(x) (sizeof(x) / sizeof((x)[0]))

References to macro arguments should always be enclosed in
parentheses; otherwise you can run into some really nasty problems
with operator precedence. Remember that the argument is expanded into
the text, not into the expression tree.

Care to provide a concrete example of a *correct* NUM_ELTS() invocation
where the extra parentheses make any difference?

Dan

 

[Dan Pop]

OTOH, I've seen ([sur]real code in [sur]real system) something like:

#define return(x) \
{ \
printf("%d\n", x); \
/* 10 or so lines of "debugging" code */
return 0; \
}

In order to use this "facility", return *had* to be coded with parentheses
around value. If that was a good practice is beside the point on hand.

Turning keywords into macros is already bad, but giving these macros
misleading semantics is downright atrocious. To inject some sanity into
such a macro, it should look like this:

#define return(x) \
{ \
printf("%d\n", (int)(x)); \
/* 10 or so lines of "debugging" code */ \
return x; \
}

Still has a problem with functions returning structures or unions, but
it requires a compile time diagnostic. And the basic semantics
of return are preserved (the function still returns what it was
supposed to return).

Dan

 

[Glen Herrmannsfeldt]

In <qchmb.9047$9E1.40254@attbi_s52> "Glen Herrmannsfeldt"

That's because something else is *usually* following the right
parenthesis. And even when there is nothing else, many people prefer
to write the semicolon on a separate line.

Yes, and also the difference between languages with, and without, reserved
words.

PL/I doesn't have reserved words, so that procedure calls must either be in
an expression, such as part of an assignment statement, or from a CALL
statement.

But C already confuses the issue between statements and function calls.
The exit() function is similar to the STOP statement in PL/I and Fortran,
though it could be considered related to return. Though I do agree that
having return as a function call would be very strange. It does seem that
exit would make more sense as a statement than a function.

-- glen

 

[Keith Thompson]

I would write that as

#define NUM_ELTS(x) (sizeof(x) / sizeof((x)[0]))

References to macro arguments should always be enclosed in
parentheses; otherwise you can run into some really nasty problems
with operator precedence. Remember that the argument is expanded into
the text, not into the expression tree.

Care to provide a concrete example of a *correct* NUM_ELTS() invocation
where the extra parentheses make any difference?

I can't think of one, and there may not be one, but I'd much rather
add the parentheses than take the time to convince myself that they're
not necessary in this particular instance.

 

[Joe Wright]

Yes, and also the difference between languages with, and without, reserved
words.

PL/I doesn't have reserved words, so that procedure calls must either be in
an expression, such as part of an assignment statement, or from a CALL
statement.

But C already confuses the issue between statements and function calls.
The exit() function is similar to the STOP statement in PL/I and Fortran,
though it could be considered related to return. Though I do agree that
having return as a function call would be very strange. It does seem that
exit would make more sense as a statement than a function.

Nonetheless, it is a function. Several years ago I examined some C
startup and shutdown. The start: label set up stuff from the command
processor arguments, argc and argv, and then called
'exit(main(argc,argv))'. exit() saved main()'s return value and, after
'closing' the C environment, returned it to the command processor (an
int value). Of course this is annecdotal and may have nothing to do with
C today.

 

[Dan Pop]

But C already confuses the issue between statements and function calls.
The exit() function is similar to the STOP statement in PL/I and Fortran,
though it could be considered related to return.

Can't see much similarity between the exit() function and the return
statement. They perform completely different actions, the only thing
they have in common being that the execution of the current function
is terminated. But, then again, the same is true for the abort(),
longjmp() and _Exit() functions (the latter is a C99 feature).

Though I do agree that
having return as a function call would be very strange. It does seem that
exit would make more sense as a statement than a function.

Then, you'd have to make abort, longjmp and _Exit statements, too, to be
consistent. OTOH, C being neither PL/I nor Fortran, there is precious
little point in using these languages as a model. Next thing, you'll
want all the I/O to be moved from the library to the language proper,
because this is how Fortran does it. And so on...

Dan

 

[Dan Pop]

Nonetheless, it is a function. Several years ago I examined some C
startup and shutdown. The start: label set up stuff from the command
processor arguments, argc and argv, and then called
'exit(main(argc,argv))'. exit() saved main()'s return value and, after
'closing' the C environment, returned it to the command processor (an
int value). Of course this is annecdotal and may have nothing to do with
C today.

It is perfectly consistent with the current C standard. It's just that
that a C99 compiler must be careful to automatically insert a return 0
statement at the end of main, if the execution of main can ever reach that
point. C89 doesn't even require this automatic insertion: exit() will
proceed with whatever garbage comes as the return value of main(), without
invoking undefined behaviour.

Dan

 

[Dan Pop]

I would write that as

#define NUM_ELTS(x) (sizeof(x) / sizeof((x)[0]))

References to macro arguments should always be enclosed in
parentheses; otherwise you can run into some really nasty problems
with operator precedence. Remember that the argument is expanded into
the text, not into the expression tree.

Care to provide a concrete example of a *correct* NUM_ELTS() invocation
where the extra parentheses make any difference?

I can't think of one, and there may not be one, but I'd much rather
add the parentheses than take the time to convince myself that they're
not necessary in this particular instance.

Then, it's a matter of personal style, rather than one of correctness
(in the context of the macro under discussion). Big difference!

Dan