Nasty bug

[Richard Flamsholt S0rensen]

In article <11842 at ogicse.ogi.edu> schaefer at ogicse.ogi.edu (Barton E. Schaefer) writes:
>} | >In article <0093BF08.7F3834E0 at rigel.efd.lth.se>, e89hse at rigel.efd.lth.se
>} | >writes... 
>} | >>... Therefore &f is a ptr to double rather than a
>} | >>ptr to float as one would expect looking at the declartion.

>ANSI has nothing to do with it.  Not knowing the type before invocation
>also has nothing to do with it.  The only reason that floats are widened
>to double in a function call is because they are widened to double in
>all expression contexts.  Similarly with char or short to int.
 ^^^^^^^^^^^^^^^^^^^^^^^

  Nope. ANSI states, that floats remain floats unless the expression
contains more precise types, that is long double or double, in which
case the float in converted. Therefore, if the float is the only
parameter to a function it is *not* converted to a double in the
expression, regardless of how the function was declared.

  Nothing has changed to the treatment of chars and shorts. These (and
enums and bitfields) are still subject to integral promotion when
found in an expression.

  Hmmm <thinking> - I might as well quote from app. A in K&R II, to
make it totally clear:

\begin{illegitimate quote ;-}

  First, if either operand is a long double, the other is converted to
long double.
Otherwise, if either operand is a double, the other is converted to double.
Otherwise, if either operand is a float, the other is converted to float.
Otherwise, the integral promotion is performed on both operands;
[lotsa stuff about long/signed/unsigned/implementation dependencies deleted]

\end{quote}

  As K&R sum it up: "The 'usual arithmetic conversions' has changed,
essentially from 'for integers, unsigned always wins; for floating
point, always use double' to 'promote to the smallest capacious-enough
type'".

  CU.

--
/Richard Flamsholt
richard at iesd.auc.dk