Empty parentheses

[Christopher Benson-Manica]

I understand the rationale behind declaring function definitions such as

int main() { return 0; } /* empty parentheses */

obsolete, but I haven't been able to find out why Dennis Ritchie despised them
enough to call them an "abomination." Comments and/or links appreciated.

 

[xarax]

I understand the rationale behind declaring function definitions such as

int main() { return 0; } /* empty parentheses */

obsolete, but I haven't been able to find out why Dennis Ritchie despised them
enough to call them an "abomination." Comments and/or links appreciated.

IIRC, the empty parens is the same as:

int main(...);

which means variable number of arguments. VARARGS
are pita, and have implementation-dependent issues.

If you really want an empty parameter list,
then the proper declaration is:

int main(void);

My brain is fuzzy on this, so if I made a boo-boo
here, please correct me.

 

[Mark A. Odell]

IIRC, the empty parens is the same as:

int main(...);

No, it doesn't. It means use the first-encountered usage to complete
the prototype.

 

[Dan Pop]

I understand the rationale behind declaring function definitions such as

int main() { return 0; } /* empty parentheses */

obsolete, but I haven't been able to find out why Dennis Ritchie despised them
enough to call them an "abomination."

Please elaborate.

Dan

 

[Dan Pop]

No, it doesn't. It means use the first-encountered usage to complete
the prototype.

Nope, it doesn't. It means this definition/declaration doesn't
provide a prototype for this function.

You're *severely* confused if you believe that the the
first-encountered usage has any relevance whatsoever. The following
code does NOT require any diagnostic:

void foo();
...
foo(1);
foo(1, 2);
foo(1, 2, 3);

although it's obvious that at most one of these calls can be correct.
It's a clear case of undefined behaviour.

Dan

 

[Derk Gwen]

# I understand the rationale behind declaring function definitions such as
#
# int main() { return 0; } /* empty parentheses */
#
# obsolete, but I haven't been able to find out why Dennis Ritchie despised them
# enough to call them an "abomination." Comments and/or links appreciated.

P'raps in comparison to how Algol 60 and 68 and Pascal and other such
languages handle the same issue.

 

[Christopher Benson-Manica]

Please elaborate.

Basically, I want to know how Dennis Ritchie and the Standards Committee can
arrive at diametrically opposed positions regarding empty parentheses. Why
does Dennis believe the syntax should be retained? Presumably it isn't
because he's a crackpot, because various important people (like Bjarne
Stroustrup) agree with his reasoning.

 

[Mark A. Odell]

Nope, it doesn't. It means this definition/declaration doesn't
provide a prototype for this function.

What should I have said?

 

[P.J. Plauger]

Basically, I want to know how Dennis Ritchie and the Standards Committee can
arrive at diametrically opposed positions regarding empty parentheses. Why
does Dennis believe the syntax should be retained? Presumably it isn't
because he's a crackpot, because various important people (like Bjarne
Stroustrup) agree with his reasoning.

I believe the issue has been slightly misstated. The original C language
that Ritchie developed had no mechanism for making the argument types a
part of the function type. The C committee added what we call function
prototypes to remedy what was widely perceived as a clear deficiency.
(We modeled those prototypes largely on previous C++ work, but not entirely.
For example, I had developed a commercial C compiler as early as 1975 that
had something similar.)

The quandary we then faced was what to do about backward compatibility.
Ritchie stated a strong dislike for having two mechanisms that did much
the same thing, only differently. The committee was sympathetic with that
view, but had a practical problem to solve. So we left the 'T f()' notation
to declare f as a function returning T with no constraints on argument
types. We also added 'T f(void)' as a way of clearly stating that f was
constrained to have no arguments, and the ... notation for a varying length
argument list with no type constraints. The rules for mixing old and new
style declarations and definitions we worked out to minimize surprises.
(A major contribution was Sam Harbison's rule about implicit prototypes,
which we quickly dubbed the Miranda Rule.)

None of us liked having two similar but different rules for declaration.
Many of us regretted parting company with C++ on the meaning of 'T f()'.
Ritchie was gracious enough to acknowledge that what we did was probably
necessary, however undesirable. I haven't heard the term 'abomination'
applied to this situation (except possibly by C++ zealots) for nearly
20 years now.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Arthur J. O'Dwyer]

What should I have said?

From Dan's response, I gather that you should have said,
"No, it doesn't. It means use the first encountered *prototype*
to complete the prototype, and *until then* just assume that the
user wants the default promotions applied to the arguments in
any calls to that function."

A function "usage" means a function call, I'd say:

foo(1) foo("abcd")

A function "prototype" means a prototype:

int foo(int); void foo(const char *p) { }


HTH,
-Arthur

 

[Jeremy Yallop]

From Dan's response, I gather that you should have said,
"No, it doesn't. It means use the first encountered *prototype*
to complete the prototype, and *until then* just assume that the
user wants the default promotions applied to the arguments in
any calls to that function."

Still not quite right, I'm afraid. Going by the OP's example code
we're talking about an empty argument list in a function /definition/.
In this case the function is defined to take no arguments, and calls
to the function which supply arguments have undefined behaviour (and
so need not be diagnosed) unless there's a separate prototype in scope
in which case such calls violate a constraint.

Jeremy.