Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!pdn!tscs!tct!chip From: chip@tct.uucp (Chip Salzenberg) Newsgroups: comp.lang.c Subject: Re: ANSI C -> non-ANSI C Message-ID: <275CFEE4.3D9@tct.uucp> Date: 5 Dec 90 14:06:28 GMT References: <14630@smoke.brl.mil> <2880@lupine.NCD.COM> Organization: Teltronics/TCT, Sarasota, FL Lines: 32 According to rfg@NCD.COM (Ron Guilmette): >What I have always planned on doing (if I ever get the time) is to simply >add another (optional) warning to GCC which would warn you about all >actual parameters to (prototyped) functions which get an implicit change >of representation by virtue of being passed into a formal parameter of >a sufficiently different type to require such a change of representation. Such a warning is too lax. You need warnings wherever a parameter value, after default promotions of char->int, short->int, float->double, etc., is not of the *exact* same type as the prototyped parameter. I would make two exceptions to the above rule. Character pointers and void pointers are guaranteed by the standard always to have the same representation, so we can consider them to be equivalent for purposes of parameter passing. A similar guarantee exists about the signed and unsigned variants of integral types, so they also may be considered identical. As an example, one machine (VAX) provides int and long types with the same representation, whereas the next machine ('286 large model) does not. Passing "0" for a long parameter thus will require a "(long)" cast for complete equivalence without prototypes, no matter which machine you happen to be using to run GCC. If the aim is to provide prototype-free code that works just like the prototyped code, then the warning must be based on portability, not a particular machine's data representation. -- Chip Salzenberg at Teltronics/TCT , "I'm really sorry I feel this need to insult some people..." -- John F. Haugh II (He thinks HE'S sorry?)