Path: utzoo!attcan!uunet!cs.utexas.edu!usc!bloom-beacon!envy.pika.mit.edu!scs
From: scs@envy.pika.mit.edu (Steve Summit)
Newsgroups: comp.lang.c
Subject: Re: consistency in declaration
Message-ID: <12366@bloom-beacon.MIT.EDU>
Date: 1 Jul 89 22:05:00 GMT
References: <64@BLEKUL11.BITNET> <13732@haddock.ima.isc.com> <14544@watdragon.waterloo.edu>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: scs@adam.pika.mit.edu (Steve Summit)
Lines: 56

In article <64@BLEKUL11.BITNET> SAAAA04@BLEKUL11.BITNET writes:
>[compiler refuses to accept a prototype with half-named args:]
>	void foo(int , int y);
>Do I have to be consistent ? Or is this a bug in the compiler ?

In article <13732@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes:
>The pANS grammar allows this notation, and I can't find any constraint against
>it.

In article <14544@watdragon.waterloo.edu> jyegiguere@lion.waterloo.edu (Eric Giguere) writes:
>Personally I prefer the approach that a
>prototype either declares identifiers for all the parameters or leaves them
>all out.  I really can't see any reason for the inconsistent notation.

An old and perhaps waning tenet of the C/Unix philosophy has been
not to disallow things for arbitrary reasons, but only because
they are unimplementable (or, occasionally, because they are
demonstrably useless).  This philosophy is often and justifiably
criticized for giving the user/programmer more than enough rope
to hang himself, but it is a good and consistent philosophy all
the same.  (I generally prefer it.)

Some time ago, I don't remember why, I wanted to name some of the
arguments within a prototype (the ones easily confused) but not
others (perhaps their type or placement made their use obvious
and rendered an explicit name superfluous).  When the compiler
(Microsoft's) disallowed it, I chalked up another one for
needless restrictions, not realizing that the pANS perhaps
legitimized my construction.

One easy test for whether a restriction is necessary is whether
the code that generates the error message also protects later
sections of code, or is used only to generate the error message.
In this case, it is obvious that the error message is not
strictly necessary, since the compiler virtually throws away
formal parameter names it finds in prototype declarations anyway.
(In fact, it must actually enter them in a special symbol table,
using a brand-new name space X3J11 invented for the purpose,
evidently only so that it can disallow

	extern int f(int x, int x);

a restriction which I find almost equally superfluous.)

On a related note, was a syntax like

	extern int f(int x, y, double z);

ever considered?  It would be handy when declaring routines
with numerous or complicated arguments, without having to split
the declaration across lines.  I think it would have been
implementable, although there is probably an ambiguity with
respect to typedef names.

                                            Steve Summit
                                            scs@adam.pika.mit.edu