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