Parameter Types in Old-Style Function Definitions
Chris Torek
chris at mimsy.umd.edu
Mon Sep 17 01:54:50 AEST 1990
>In article <26564 at mimsy.umd.edu> I wrote:
>>Note that this problem would not exist, had X3J11 chosen the correct
>>(i.e., sign-preserving) extension rules. [harangue omitted]
In article <13865 at smoke.BRL.MIL> gwyn at smoke.BRL.MIL (Doug Gwyn) writes:
>Actually the alternative was unsignedness-preserving.
Er, that is what `sign-preserving' above means: in short, `unsigned
is sticky'.
>Both sets of rules had substantial existing practice,
This is true;
>and the choice was not at all easy to make.
but this should have been false, for the reason I stated earlier:
>One of the strongest advocates for unsignedness-preserving rules later
>did an experiment to determine how much actual existing code would be
>affected by the choice, and discovered that the change fixed more bugs
>in existing code than it introduced, but much more often it had no effect.
>That pretty much confirmed the original committee evaluation.
In almost all cases, the change has no effect: the only cases where it
has an effect are in places that really `ought to' have a cast, and---
in my (on this point, not at all humble) opinion, far more importantly
---in unprototyped arguments. In the latter case, it is impossible to
calculate the type (and thus the value) of the expression without
knowing whether sizeof(short) < sizeof(int).
Now, if you accept as an axiom that unprototyped arguments are bad, the
above argument almost goes away (`almost' because you are also arguing
that *printf are evil, but they are here to stay). If, on the other
hand, you have mountains of existing code and little time to rewrite it
all....
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750)
Domain: chris at cs.umd.edu Path: uunet!mimsy!chris
More information about the Comp.std.c
mailing list