pardo@june.cs.washington.edu (David Keppel) (08/07/89)
My *impression* is that actual parameter names are local to the function. My dpANS-compliant compiler (gcc version 1.34) complains on the following program: typedef int foo; m (foo){} foo.c: parameter name omitted If I declare the parameter type, then I get a similar complaint. typedef int foo; m (foo) int foo; {} foo.c: parm types given both in parmlist and separately foo.c: parameter name omitted Is this misbehavior of my compiler, or is this compliant behavior? Please e-mail, I will summarize. ;-D on ( A four-poster computer ) Pardo -- pardo@cs.washington.edu {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo
pardo@june.cs.washington.edu (David Keppel) (08/07/89)
This is a summary of responses. pardo@june.cs.washington.edu (David Keppel) writes: | My *impression* is that actual parameter names are local to the | function. My dpANS-compliant compiler (gcc version 1.34) complains on | the following program: | | typedef int foo; | m (foo){} | | foo.c: parameter name omitted The most illuminating comment was Roger Critchlow: | It's compliant. There is an ambiguity in the grammar at the point | where m (foo has been read. The compiler wants to know whether it | has read the first identifier in an old style function declaration | or the type-name of the first parameter in a prototype style function | declarator. Rather than forcing the compiler to look ahead further | to disambiguate, the standard says that a type-name is a type-name | in this context. Thanks to all who responeded (and those who have yet to respond :-) Fooey on inews for rejecting my article the first time, just because I was trying to show what was quoted text. ;-D on ( The great plains: Farm all parameters ) Pardo -- pardo@cs.washington.edu {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo
darcy@bbm.UUCP (D'Arcy Cain) (08/09/89)
In article <8936@june.cs.washington.edu>, pardo@june.cs.washington.edu (David Keppel) writes: > My *impression* is that actual parameter names are local to the > function. My dpANS-compliant compiler (gcc version 1.34) complains on > the following program: > > typedef int foo; > m (foo){} > > foo.c: parameter name omitted > > typedef creates a new data type not a parameeter name so the above response is correct. the declaration is exactly the same as the following: m (int){} Which is obviously incorrect. D'Arcy J.M. Cain