budd@mist.cs.orst.edu (Tim Budd) (03/04/89)
Unless I am seriously mistaken in my understanding of prototypes, our version
of gcc produces an error in what I believe is a correct program.
Try the following:
extern int foo ( short );
int foo(x)
short x;
{ ; }
I get a message that the argument doesn't match the prototype.
Works fine if I use int in place of short.
Anybody know if this has been fixed?bobmon@iuvax.cs.indiana.edu (RAMontante) (03/04/89)
budd@mist.cs.orst.edu (Tim Budd) <9201@orstcs.CS.ORST.EDU> :
-
-extern int foo ( short );
-
-int foo(x)
-short x;
-{ ; }
-
-I get a message that the argument doesn't match the prototype.
-Works fine if I use int in place of short.
Although you've given a prototype for foo(), the function definition doesn't
match it --
int foo(x)
is an old-style definition. Your error message is complaining (indirectly)
that this line is incorrect, as it doesn't match the prototype. Try
int foo(short x)
{ ; }
instead. This works for me. I don't think you need the extern keyword
either.
--
Those who do not understand MSDOS are | Bob Montante (bobmon@cs.indiana.edu)
condemned to write glowingly of it in | Computer Science Department
slick, short-lived magazines. | Indiana University, Bloomington INschmidt@glacier.ics.uci.edu (Doug Schmidt) (03/05/89)
In article <9201@orstcs.CS.ORST.EDU> budd@mist.cs.orst.edu (Tim Budd) writes: ++ Unless I am seriously mistaken in my understanding of prototypes, our version ++ of gcc produces an error in what I believe is a correct program. ++ Try the following: ++ ++ extern int foo ( short ); ++ ++ int foo(x) ++ short x; ++ { ; } ++ ++ I get a message that the argument doesn't match the prototype. ++ Works fine if I use int in place of short. ++ ++ Anybody know if this has been fixed? Since this ``bug'' in gcc is reported about once every 3 weeks let me post the relevant section from the gcc.texinfo manual: ---------------------------------------- @item Users often think it is a bug when GNU CC reports an error for code like this: @example int foo (short); int foo (x) short x; @{@dots{}@} @end example The error message is correct: this code really is erroneous, because the old-style non-prototype definition passes subword integers in their promoted types. In other words, the argument is really an @code{int}, not a @code{short}. The correct prototype is this: @example int foo (int); @end example ---------------------------------------- If you don't agree with the gcc interpretation of ANSI proto-types, please post a message to bug-gcc@prep.ai.mit.edu with a quote from the latest version of the dpANS standard to substantiate your claim. thanks, Doug Schmidt -- schmidt@ics.uci.edu (ARPA) | Per me si va nella citta' dolente. office: (714) 856-4043 | Per me si va nell'eterno dolore. | Per me si va tra la perduta gente. | Lasciate ogni speranza o voi ch'entrate.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (03/05/89)
In article <9201@orstcs.CS.ORST.EDU> budd@mist.cs.orst.edu (Tim Budd) writes: >Unless I am seriously mistaken in my understanding of prototypes, our version >of gcc produces an error in what I believe is a correct program. >extern int foo ( short ); >int foo(x) >short x; >{ ; } >I get a message that the argument doesn't match the prototype. GCC is correct to complain about this usage. That's because the parameter (formal argument) doesn't match the prototype. By using an old-style function definition, you've required that `x' be passed as an int, then converted to short upon entry to the function. The prototype says that it's passed as a short in the first place. Those two functions interfaces are not in general conformable.
davis@pacific.mps.ohio-state.edu ("John E. Davis") (04/04/91)
In article <2127@gold.gvg.tek.com> shaunc@gold.gvg.tek.com (Shaun Case) writes: [...] #include <stdio.h> #define quote " #define stringize(a) (quote a"+1) main() { printf("[%s]\n",stringize(foo)); } --- cut here --- Is there some reason why this is a bad idea? I compiled it and ran it on a sun4 using CC as well as cc. It ran as expected. However it failed to run under gcc: [pacific]>gcc test.c test.c: In function main: test.c:8: `foo' undeclared (first use this function) test.c:8: (Each undeclared identifier is reported only once test.c:8: for each function it appears in.) [pacific]> So does this mean there is a bug in gcc? -- John bitnet: davis@ohstpy internet: davis@pacific.mps.ohio-state.edu
karl@ima.isc.com (Karl Heuer) (04/04/91)
In article <DAVIS.91Apr3215642@pacific.mps.ohio-state.edu> davis@pacific.mps.ohio-state.edu (John E. Davis) writes: >[The program which included] > #define quote " > #define stringize(a) (quote a"+1) >...failed to run under gcc... So does this mean there is a bug in gcc? No, since the program contains unbalanced quotes (and is therefore incorrect), the way gcc chooses to resolve the error is no more buggy than the way the Reiser cpp resolves it. If you really need stringizing (and few programs do, even if they think so), then use |#a| with ANSI compilers, |"a"| with compilers that use the Reiser cpp (or any bug-for-bug compatible cpp), and the above hack on any others. And when you encounter an implementation where none of them work, complain to the person who told you that you really needed stringizing. Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint