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.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[xarax]

"Christopher Benson-Manica" <at***@nospam.cyberspace.org> wrote in message
news:bm**********@chessie.cirr.com...

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]

"xarax" <xa***@email.com> wrote in
news:Qm***************@newsread4.news.pas.earthlin k.net:

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(...);

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

--
- Mark ->
--

[Dan Pop]

In <bm**********@chessie.cirr.com> Christopher Benson-Manica <at***@nospam.cyberspace.org> writes:

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
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <Xn********************************@130.133.1.4> "Mark A. Odell" <no****@embeddedfw.com> writes:

"xarax" <xa***@email.com> wrote in
news:Qm***************@newsread4.news.pas.earthli nk.net:

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(...);

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Derk Gwen]

Christopher Benson-Manica <at***@nospam.cyberspace.org> wrote:
# 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.

--
Derk Gwen http://derkgwen.250free.com/html/index.html
God's a skeeball fanatic.

[Christopher Benson-Manica]

Dan Pop <Da*****@cern.ch> spoke thus:

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.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Mark A. Odell]

Da*****@cern.ch (Dan Pop) wrote in news:bm**********@sunnews.cern.ch:

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(...);

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.

What should I have said?

--
- Mark ->
--

[P.J. Plauger]

"Christopher Benson-Manica" <at***@nospam.cyberspace.org> wrote in message
news:bm**********@chessie.cirr.com...

Dan Pop <Da*****@cern.ch> spoke thus:

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.

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]

On Fri, 17 Oct 2003, Mark A. Odell wrote:

Da*****@cern.ch (Dan Pop) wrote in news:bm**********@sunnews.cern.ch:
[Mark A. Odell wrote:]

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.

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]

Arthur J. O'Dwyer wrote:

On Fri, 17 Oct 2003, Mark A. Odell wrote:

Da*****@cern.ch (Dan Pop) wrote in news:bm**********@sunnews.cern.ch:
[Mark A. Odell wrote:]

>>
>>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.

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."

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.