SAAAA04@BLEKUL11.BITNET (Saaaa04) (06/13/89)
To my surprise the following happened with the waterloo C compiler (for VM/CMS)
it refuses:
void foo(int , int y);
but (of course) accepts:
void foo(int x, int y);
void foo(int , int);
Do I have to be consistent ? Or is this a bug in the compiler ?
Tongiguere@aries5.uucp (Eric Giguere) (06/15/89)
In article <64@BLEKUL11.BITNET> SAAAA04@BLEKUL11.BITNET writes: >To my surprise the following happened with the waterloo C compiler (for VM/CMS) Wow! An IBM mainframe user reading this group... >it refuses: >void foo(int , int y); >but (of course) accepts: >void foo(int x, int y); >void foo(int , int); >Do I have to be consistent ? Or is this a bug in the compiler ? It's not a bug.... it's a feature. Seriously, the ANSI specs state that a function prototype can accept types or types with IDs but not both in the same declaration. So, yes, you do have to be consistent. (I should know, I spent a lot of time debugging all the ANSI stuff we put into the compiler...) Eric Giguere 268 Phillip St #CL-46 For the curious: it's French ("jee-gair") Waterloo, Ontario N2L 6G9 Bitnet : GIGUERE at WATCSG (519) 746-6565 Internet: giguere@aries5.UWaterloo.ca "Nothing but urges from HELL!!"
awd@dbase.UUCP (Alastair Dallas) (06/16/89)
In article <64@BLEKUL11.BITNET>, SAAAA04@BLEKUL11.BITNET (Saaaa04) writes: > To my surprise the following happened with the waterloo C compiler > it refuses: > > void foo(int , int y); > > but (of course) accepts: > > void foo(int x, int y); > void foo(int , int); > > Do I have to be consistent ? Or is this a bug in the compiler ? > The same seems to be true for Microsoft C v5.1 for the IBM PC. But is consistency really that much of a burden in this case? /alastair/
karl@haddock.ima.isc.com (Karl Heuer) (06/16/89)
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 ? The pANS grammar allows this notation, and I can't find any constraint against it. I'd say it's a compiler bug. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
dfp@cbnewsl.ATT.COM (david.f.prosser) (06/16/89)
In article <263@maytag.waterloo.edu> giguere@aries5.waterloo.edu (Eric Giguere) writes: }In article <64@BLEKUL11.BITNET> SAAAA04@BLEKUL11.BITNET writes: }>To my surprise the following happened with the waterloo C compiler (for VM/CMS) } }Wow! An IBM mainframe user reading this group... } }>it refuses: } }>void foo(int , int y); } }>but (of course) accepts: } }>void foo(int x, int y); }>void foo(int , int); } }>Do I have to be consistent ? Or is this a bug in the compiler ? } }It's not a bug.... it's a feature. Seriously, the ANSI specs state that }a function prototype can accept types or types with IDs but not both }in the same declaration. So, yes, you do have to be consistent. } }(I should know, I spent a lot of time debugging all the ANSI stuff we put }into the compiler...) } }Eric Giguere 268 Phillip St #CL-46 }For the curious: it's French ("jee-gair") Waterloo, Ontario N2L 6G9 }Bitnet : GIGUERE at WATCSG (519) 746-6565 }Internet: giguere@aries5.UWaterloo.ca "Nothing but urges from HELL!!" Not quite. The pANS requires that there be identifiers present for all prototype parameters only for a function's definition. If it's just a declaration, one can arbitrarily include or exclude the identifiers. It would have been nice to be able to exclude identifiers even in function definitions as that would be a linguistic way of stating that the parameter is unused. C++ includes this feature, but the X3J11 technical committee didn't buy into it. Dave Prosser ...not an official X3J11 answer...
scjones@sdrc.UUCP (Larry Jones) (06/17/89)
In article <263@maytag.waterloo.edu>, giguere@aries5.uucp (Eric Giguere) writes: > In article <64@BLEKUL11.BITNET> SAAAA04@BLEKUL11.BITNET writes: > [ is "void foo(int , int y);" a valid declaration? ] > > Seriously, the ANSI specs state that > a function prototype can accept types or types with IDs but not both > in the same declaration. So, yes, you do have to be consistent. > > (I should know, I spent a lot of time debugging all the ANSI stuff we put > into the compiler...) References, please. I checked the draft and I don't see anything that prohibits it. The relevant part of the grammar is: parameter-list: parameter-declaration parameter-list , parameter-declaration parameter-declaration: declaration-specifiers declarator declaration-specifiers abstract-declarator(opt) which pretty clearly allows it, and I don't see any constraints that prohibit it. ---- Larry Jones UUCP: uunet!sdrc!scjones SDRC scjones@SDRC.UU.NET 2000 Eastman Dr. BIX: ltl Milford, OH 45150-2789 AT&T: (513) 576-2070 "You can't get a body like mine in a bottle -- unless you push REAL HARD." - Judy Tenuta / Dr. Pepper
jyegiguere@lion.waterloo.edu (Eric Giguere) (06/17/89)
In article <13732@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: >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 ? > >The pANS grammar allows this notation, and I can't find any constraint against >it. I'd say it's a compiler bug. Compiler bug? The specific phrasing in the pANS is "A parameter type list specifies the types of, and may declare identifiers for, the parameters of the function." (3.5.4.3) As Karl says, this does not in fact disallow the case above. Nor does it allow it... it's ambiguous. 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. In any case that's the way we've implemented it in Waterloo C. Apparently that's the way Microsoft does it as well... Watcom C probably does it that way too.... but I suppose we're quibbling over very minor details. Let's get back to trigraphs :-) Eric Giguere 268 Phillip St #CL-46 For the curious: it's French ("jee-gair") Waterloo, Ontario N2L 6G9 Bitnet : GIGUERE at WATCSG (519) 746-6565 Internet: giguere@aries5.UWaterloo.ca "Nothing but urges from HELL!!"
karl@haddock.ima.isc.com (Karl Heuer) (06/20/89)
In article <14544@watdragon.waterloo.edu> jyegiguere@lion.waterloo.edu (Eric Giguere) writes: >>>[compiler refuses to accept a prototype with half-named args:] >>> void foo(int , int y); >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. I agree, but personal preferences shouldn't be strictly enforced by the compiler. My recommendation is to downgrade it to a warning. (The pANS imposes no constraints on warnings, though personally I feel that everything questionable should have an OPTIONAL warning attached to it.) Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
dfp@cbnewsl.ATT.COM (david.f.prosser) (06/20/89)
In article <14544@watdragon.waterloo.edu> jyegiguere@lion.waterloo.edu (Eric Giguere) writes: >In article <13732@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: >>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 ? >> >>The pANS grammar allows this notation, and I can't find any constraint against >>it. I'd say it's a compiler bug. > >Compiler bug? The specific phrasing in the pANS is > > "A parameter type list specifies the types of, and may declare > identifiers for, the parameters of the function." (3.5.4.3) > >As Karl says, this does not in fact disallow the case above. Nor does it >allow it... it's ambiguous. 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. The wording in the pANS is not ambiguous in this case. What it doesn't directly state is that the parameters in a declaration may or may not be independently present. There are a lot of places like this in the pANS. Since there is a statement that the identifiers must be present in a definition: "If the declarator [in a function definition] includes a parameter type list, the declaration of each parameter shall include an identifier (except for the special case of a parameter list consisting of a single parameter of type void, in which shall not be an identifier)." [section 3.7.1] I believe this a clearly a case of the pANS requiring that conforming ANSI C compilers accept both named and unnamed parameter declarations in a non- definition prototype. > >In any case that's the way we've implemented it in Waterloo C. Apparently >that's the way Microsoft does it as well... Watcom C probably does it that >way too.... but I suppose we're quibbling over very minor details. By my reading, then these compilers are not going to be ANSI C conforming by the time that the pANS losses its "p", not that this is an important feature in anybody's book. On the other hand, if it were also allowed in a definition context, then it *would* be a minor, but important, feature to me. > >Eric Giguere 268 Phillip St #CL-46 >For the curious: it's French ("jee-gair") Waterloo, Ontario N2L 6G9 >Bitnet : GIGUERE at WATCSG (519) 746-6565 >Internet: giguere@aries5.UWaterloo.ca "Nothing but urges from HELL!!" Dave Prosser ...not an official X3J11 answer....
scs@envy.pika.mit.edu (Steve Summit) (07/02/89)
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
jagardner@watmath.waterloo.edu (Jim Gardner) (07/22/89)
In article <14544@watdragon.waterloo.edu> jyegiguere@lion.waterloo.edu (Eric Giguere) writes: >In article <13732@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: >>it. I'd say it's a compiler bug. > >Compiler bug? The specific phrasing in the pANS is > > "A parameter type list specifies the types of, and may declare > identifiers for, the parameters of the function." (3.5.4.3) > >As Karl says, this does not in fact disallow the case above. Nor does it >allow it... it's ambiguous. 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. The phrase you quote does not impose any restrictions. The grammar given in the standard allows mixing. Unless there's some constraint elsewhere in the standard, it seems clear that mixing is allowed. By imposing the restriction, you are demanding that every writer of a portable ANSI conforming program come to the same conclusion as you, and personally impose the same restriction. I say your compiler's broken. (I'm not defending the mixing of parameter declaration identifiers. It seems silly, but macros and automatic code generators can result in silly, but correct, code. <- is that an oxymoron?) > >In any case that's the way we've implemented it in Waterloo C. Apparently >that's the way Microsoft does it as well... Watcom C probably does it that >way too.... but I suppose we're quibbling over very minor details. Let's >get back to trigraphs :-) Just to confuse the world, the University of Waterloo C compiler allows you to mix the declarations. (the GCOS8 one, probably the PC and Port ones too) David Tanguay
jyegiguere@lion.waterloo.edu (Eric Giguere) (07/23/89)
Alright, it would seem I'm outvoted on this parm-list-with-and-without-IDs
discussion.... maybe I'll suggest to my boss that we support it, but I think
we have other more important things to worry about. Then again, we never
claim anywhere in our docs to be completely ANSI-compatible, only that we
support most of the draft proposed Standard... we've always hesitated to use
the phrase "ANSI-compatible" when there is no such thing (officially) yet
and the draft kept changing... Remember the good ol' "noalias" keyword
a couple of drafts back? I know of at least one compiler (hint: it also
comes out of Waterloo) that supported it... then the Committee took it out.
Ooops! Well, it's not as if that would break existing code or anything.
So for now I guess I would just label the whole mess as an "unsupported
feature" and leave it at that.
Eric Giguere 268 Phillip St #CL-46
For the curious: it's French ("jee-gair") Waterloo, Ontario N2L 6G9
Bitnet : GIGUERE at WATCSG (519) 746-6565
Internet: giguere@aries5.UWaterloo.ca "Nothing but urges from HELL!!"