Whitespace before opening paren in function call?

[C. J. Clegg]

I read somewhere that in a function call, one should never put
whitespace in front of the opening paren.

Example:

int theArg;

x = foo ( theArg ); /* bad */
x = foo( theArg ); /* OK, no white before opening paren */

The reasoning, if I recall it correctly, had something to do with the
difference between a function call and a macro call, i.e. if the first
example above is actually a call to a macro and not a function, it
might not work as expected.

The place where I read this makes an emphatic point that a programmer
is never entitled to know if an apparent function call is actually a
call to a macro, so one should not put any whitespace in front of the
call, so that it will work in all cases.

Can someone please refresh my memory on this and fill in the details?

Thanks...

 

[Keith Thompson]

I read somewhere that in a function call, one should never put
whitespace in front of the opening paren.

Example:

int theArg;

x = foo ( theArg ); /* bad */
x = foo( theArg ); /* OK, no white before opening paren */

The reasoning, if I recall it correctly, had something to do with the
difference between a function call and a macro call, i.e. if the first
example above is actually a call to a macro and not a function, it
might not work as expected.

The place where I read this makes an emphatic point that a programmer
is never entitled to know if an apparent function call is actually a
call to a macro, so one should not put any whitespace in front of the
call, so that it will work in all cases.

Can someone please refresh my memory on this and fill in the details?

Some coding standards might have something to day about this, but as
far as the language is concerned it doesn't matter. Whitespace
between an identifier and a left parenthesis is optional regardless of
whether the identifier is the name of a function or of a function-like
macro, and has been at least since the 1989 ANSI C standard (possibly
longer).

One possible source of confusion is that whitespace in front of the
'(' is significant in a macro *definition*. For example:

#define FUNCTION_LIKE() blah
#define OBJECT_LIKE () blah

An invocation of the FUNCTION_LIKE macro must be followed by
parentheses, and will expand to the token blah.

An invocation of the OBJECT_LIKE macro needn't be followed by
parentheses (and if it is they aren't part of the invocation); it
expands to the three tokens (, ), and blah.

There may be historical reasons for the concern. K&R1 (published in
1978) says the following in a discussion of a macro with arguments
(page 87):

There are even some purely lexical problems: there can be no space
between the macro name and the left parenthesis that introduces
its argument list.

But I'm not certain that refers to invocations of the macro; it may
just refer to macro definitions, where the "no space" rule is still in
the language. Appendix A doesn't mention a "no space" rule for macro
invocations. "gcc -E -traditional" allows a space, for whatever
that's worth. In any case, that sentence was dropped in K&R2&R2.

 

[Kaz Kylheku]

I read somewhere that in a function call, one should never put
whitespace in front of the opening paren.

This is a stylistic recommendation, and not a matter of correctness.

Example:

int theArg;

x = foo ( theArg ); /* bad */
x = foo( theArg ); /* OK, no white before opening paren */

The only situation in which whitespace between an identifier
and an opening parenthesis is semantically significant in C is
in a #define directive:

// function-like macro with one argument

#define foo(abc) ...

// object like macro expanding to (abc) ...

#define foo (abc) ...

The reasoning, if I recall it correctly, had something to do with the
difference between a function call and a macro call, i.e. if the first
example above is actually a call to a macro and not a function, it
might not work as expected.

Whoever was handing down this silly rationale was perhaps burned
by some old, non-conforming compiler.

I hope you can appreciate that it's impractical to devise a C programming style
which incorporates workarounds for all bugs in all C compilers that have ever
been built. If there once existed a compiler somewhere which doesn't understand
switch statements properly, and is still in use by some people, do you avoid
switch statements?

Program for clarity. Work around bugs in whatever you are working with
at the moment.

Any compiler still in use which treats foo(abc) as a macro call, but
not foo (abc), ought to be regarded as poor quality junk.