white space between function indentifier and (

[Chris DeVoney]

Posted to net.lang.c and net.micro.pc (net.micro.pc was where this orginated).

John Lowry <bbnccv!jlowry at bbnccv.ARPA> originally wrote a complaint about the
Eco-C compiler. The complaint was that compiler barfs on printf (...). I 
responded by saying that K&R nor ANSI expressly condone the practive of
a space between the identifier and the openning parentheses. Below is a summary
of the mailed and posted responses:

*******************************************************************************

>From inuxc!ihnp4!ucla-cs!lcc!richard Wed Aug  7 05:18:29 1985

I cannot find any place in K&R which explicitly allows a newline to follow
a semicolon, but any compiler which forbids this would be severely broken!
What K&R does say is (Appendix A, Section 2, page 179):

	Blanks, tabs, newlines, and comments (collectively, 'white space')
	as described below are ignored except as they serve to separate
	otherwise adjacent identifiers, keywords, and constants.

There is no exception in the above quote which implies that white space
before a left parenthesis is significant.  In this context, the phrase
(K&R, p. 186) "a hitherto unseen identifier followed immediately by a left
parenthesis" should be interpreted as implying that the left parenthesis
must be the next TOKEN!

As far as the ANSI standard goes, the April 30 draft of X3J11 does not use
wording similar to K&R's.  It states:

	If no declaration is in scope for an identifier used as the first
	expression in a function call, the identifier is implicitly
	declared exactly as if ...

There is no reason to believe that white space should be illegal between
the "first expression" and the argument list.

Richard M. Mathews
Locus Computing Corporation		       lcc.richard at LOCUS.UCLA.EDU
				{ucivax,trwrb}!lcc!richard
 {ihnp4,randvax,sdcrdcf,ucbvax,trwspp}!ucla-cs!lcc!richard

******************************************************************************

>From inuxc!ihnp4!utzoo!lsuc!msb Thu Aug  8 11:51:47 1985

That wasn't hard to find.  First page of Appendix A.

Since this is in the paragraph on LEXICAL conventions, this means
this ignoring takes place before any SYNTACTIC analysis such as
determining that "printf (" is a function call.

Mark Brader

******************************************************************************

>From inuxc!ihnp4!mhuxn!mhuxr!ulysses!allegra!mit-eddie!think!harvard!seismo!umcp-cs!chris Sat Aug  3 23:25:17 1985

...and received: the problem was that the original wording was ambiguous.
The *intent* is that any identifier followed by a left parenthesis, with
nothing other than whitespace intervening, is a function call.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris at umcp-cs		ARPA:	chris at maryland

********************************************************************************

>From inuxc!ihnp4!qantel!hplabs!tektronix!uw-beaver!uw-june!entropy!dataio!bright Sat Aug  3 10:15:18 1985

C is a tokenized language, and since 'printf' and '(' are separate
tokens, any amount of whitespace may appear between them. The only time
that whitespace has to be handled in the definition of the language is
in dealing with the preprocessor.

Walter Bright

(cdv: unforunately, I lost his signature)

*******************************************************************************

>From inuxc!ihnp4!qantel!dual!lll-crg!seismo!brl-tgr!tgr!Purtill at MIT-MULTICS.ARPA Tue Aug  6 19:54:55 1985

          Space characters,... - collectively called *white space* - are
    ignored except as they seperate tokens.
          
And of course "printf" and "(" are both tokens (identifier and operator
resp.)

       Mark
^.-.^  Purtill at MIT-MULTICS.ARPA    **Insert favorite disclaimer here**
(("))  2-032 MIT Cambrige MA 02139

******************************************************************************

I will summarize Tim Leslie at Ecosoft's reasoning for not allowing spaces
between the function identifier and parens.

K&R, Appendix A, pg 186, para 4, "Primary Expressions"

"... As indicated below, a hitherto unseen identfiier followed *immediately*
by a left parenthesis is contentually declared to represent a function returning
an integer; thus ..."

The reasoning is that an unseen identifier surrounded by white space could
be an undefined/undeclared variable missing an additional token. Most of
those using the Ecosoft compilers know that the compiler can "nail" the
offending syntax down to the line and character number. Hence, the compiler
believes that for:

	i = bozo (a * b);

bozo is an undeclared variable as this statment might be missing a token 
between the identifier and left parenthesis. The intent of the expression 
might have been:

	i = bozo / (a * b);

If the compiler interpretes the first expression improperly as a function, no
error indication would be given until link time when an unresolved global
would be mentioned or later in the program when a type mismatch would occur.
It would be difficult for the compiler to complain about the proper line.
This is why Tim used this interpetation.

The second reason is that the paragraph from K&R has a similarity to the
definiton for a parameterized macro, where no spaces are allowed between
the identifier and parenthesis. However, in this section K&R explicitly
deny the use of white space. In the section on primary expressions, white
space is alluded to and open to interpretation.

However, Tim has asceeded to the wishes of the UNIX community. The next 
versions of the compilers will gobble white space between the identifier and
parenthesis. Let it not be said that vendors are unresponsive to the
desires of the C community (nor that Ecosoft is the only vendor who listens
to their customers; all compiler houses do!).

Accordingly:
I, Chris DeVoney, under the eyes of God and my country, hereby recant my 
previous response about white space and will deny under oath in any court of
law that I mentioned the thing in the first place.

I thank all those who responded.

-- 
Chris DeVoney				voice: 317/842-7162
Que Corporation				uucp:  ihnp4!inuxc!que!chris
Indianapolis, IN 

#include <trademarks.all && disclaimer.all> /* you know what these are for */