Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uflorida!haven!uvaarpa!babbage!mac3n
From: mac3n@babbage.acc.virginia.edu (Alex Colvin)
Newsgroups: comp.lang.c
Subject: Re: function prototype problem
Summary: widening, narrowing, big & little ends
Message-ID: <412@babbage.acc.virginia.edu>
Date: 18 Nov 88 16:05:48 GMT
References: <310@drd.UUCP> <1704@scolex> <8889@smoke.BRL.MIL> <1736@scolex> <8916@smoke.BRL.MIL>
Distribution: na
Organization: University of Virginia
Lines: 19

In article <8916@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes:
> In article <1736@scolex> seanf@sco.COM (Sean Fagan) writes:
> >So, the moral of the story:  Don't pass in char's, short's, or float's to
> >your subroutines unless you want a Real(tm) ANSI C compiler to choke on it
> 
> No, that's the wrong moral.  The correct conclusion is that prototypes
> for old-style-defined functions must declare the parameters with the
> correctly widened types.

It's true.  Be careful declaring a (float) parameter in K&R C.  What
happens when you pass its address to something that expects (float *)?

Most stuff works OK when you're on a little-end address machine where the
beginning of (int) looks like (char).  Less common is where the beginning of
(double) looks like a (float).  Kids, don't try this on your big-end or
word addressed machines at home.  You'll get the wrong (char).

I understand that ANSI C may be an annoyance to those of you with VAXes, but I
can't afford one and it sure helps me.