The first gcc example upcasts l to `double` before the addition, then
casts the result of the addition down to `long` which loses
information by truncation and possibly range (which can be triggered
by either the `unsigned long` or the `double`; but neither one
triggers that in this particular example). `long` and `unsigned long`
are below both `float` and `double` in the hierarchy because the
exponent can easily push a value out of their range.

I'll also note that currently `fromIntegral` in Haskell doesn't verify
range, so one can argue that a casting implementation has prior art to
refer to.

On Wed, Jun 1, 2022 at 2:52 PM Olaf Klinke <olf@aatal-apotheke.de> wrote:
>
> On Wed, 2022-06-01 at 02:54 +0300, Miao ZhiCheng wrote:
> >  it also makes me think how the C language style of
> > "implicit casting" is working under the hood.
>
> Ooh, good question! I am not a C expert. Can anyone more experienced
> share some details, please? In Kernighan & Ritchie I found this
> wonderful sentence at the beginning of Section 2.7:
> "In general, the only conversions that happen automatically are those
> that make sense, ..."
> And further:
>
> "Implicit arithmetic conversions work much as expected. In general, if
> an operator like + or * which takes two operands (a 'binary operator')
> has operands of different types, the 'lower' type is promoted to the
> 'higher' type before the operation proceeds."
>
> This suggests that C, too, maintains a directed hierarchy [1] of
> (numeric) types in which implicit conversions are performed. Attempt to
> perform an explicit conversion not of this hierarchy (e.g. a struct) is
> a compile-time error.
> Except, the hierarchy is not really directed, because implicitly
> casting "down" or "across" the hierarchy is also allowed. The following
> is accepted by gcc 8.3.0.
>   unsigned long l = 3000;
>   double d = -3.4;
>   long   x = l + d; // which is higher: long or double?
>   double y = l + d;
> K & R mention that implicit casting can lose information, e.g. by
> rounding. I suppose a sane implementation in Haskell would want to
> avoid that.
>
> Olaf
>
> [1] https://www.guru99.com/images/1/020819_0641_TypeCasting2.png
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



--
brandon s allbery kf8nh
allbery.b@gmail.com