Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!bloom-beacon!athena.mit.edu!raeburn
From: raeburn@athena.mit.edu (Ken Raeburn)
Newsgroups: comp.lang.c
Subject: Re: Prototypes with old style definitions
Message-ID: <1990Feb14.075349.24306@athena.mit.edu>
Date: 14 Feb 90 07:53:49 GMT
References: <626@cameron.cs.duke.edu> <2329@dataio.Data-IO.COM> <1990Feb13.133503.19793@Jhereg.Minnetech.MN.ORG>
Sender: news@athena.mit.edu (News system)
Reply-To: Raeburn@MIT.Edu (Ken Raeburn)
Organization: Massachusetts Institute of Technology
Lines: 47

In article <1990Feb13.133503.19793@Jhereg.Minnetech.MN.ORG> mark@Jhereg.Minnetech.MN.ORG (Mark H. Colburn) writes:
>In article <2329@dataio.Data-IO.COM> bright@Data-IO.COM (Walter Bright) writes:
(basically that
	float foo (float, int);
	float foo (x, n) float x; int n; { /* ... */ }
are incompatible, because the latter implies
	float foo (double arg_to_treat_as_float, int n))

>I was under the impression that the standard allowed parameters to be
>passed between functions without type coersion in this manner as long
>as there was a function prototype in effect.  If no function prototype
>is in effect then the second example would be correct.  However, using
>prototypes, the former should be correct.  If you wanted doubles

I had this argument a while back with a friend of mine from Lotus.  As I
recall, she was claiming that all of the ANSI C compilers she'd worked with
except gcc did what you suggest.  (I don't know which compilers or even which
machines she was working with -- mostly in the PC world, I think -- but I hope
not to have to use them.)

But there is a section of the ANS (which I can't point you to, since I don't
have my draft copy here) which says that the declaration implied by the
old-style definition is compatible only with prototypes with (among other
things) argument types that are compatible with the *promoted* type of the
corresponding argument in the definition.

The arguments I see basically go two ways:

1) Let's make the prototype not modify the behavior of the function.  This
   way, the compiled function doesn't depend on whether the prototype was
   visible (and therefore providing more information) when the definition was
   compiled.  (This is the course X3J11 chose.)

2) Let's make the prototype modify the function's behavior.  This means that
   the definition does not contain all the information about the function that
   is needed to compile it.  (Of course, to make life easier, we'll only
   require the prototype be in scope for the definition when you want to omit
   the default promotions.)  This way, we can get exactly what we want with
   our new fancy ANSI-compliant compilers, and our old crufty compilers can
   still swallow the code (since we're using "#if __STDC__", of course!), even
   though they'll waste extra space in the argument list and so forth.

I can make no claim as to what X3J11's reasoning was, but from at least one
point of view, option 1 above seems sufficiently persuasive.  (Of course,
my friend held the opposite point of view, but....)

-- Ken