[nortiero]

I think that this is a case of mismatch between two standards, not a bug. The C standard allows higher precision values to be used in place of lesser ones (extended precision vs double) and REQUIRES conversion to the correct precision during assignment (or casting). Also, the C abstract machine has the option to store those values when/if it deems opportune, it won't change observables as defined there.

On the other side, IEEE 754 allows extended precision to be used in place of double and of course requires that any chosen precision be kept or else.

But C Standard mandates IEEE 754 , too!

It seems to me that modern C deliberately chose to ignore such kind of mismatch in the name of (substantial) performance gains. K&R, good or bad, was way simpler!

[leni536]

> But C Standard mandates IEEE 754 , too!

Are you sure? I can't find it in the standard, specifically not in [1] page 28., section 5.2.4.2.2.

[1] (the final draft of C1X, dated 12 April 2011) http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

[nortiero]

You are absolutely correct, "mandates" is too strong a word. Annex F, which is normative, have a way out by not setting __STDC_IEC_559__, GCC6.3.0 does set a slightly different GCC_IEC_559. Yet I think that my argument still holds:

floating point calculations can be executed at wider range (§5.1.2.3.12);

assignments and casts are under obligation to wipe out that extra precision (§ same paragraph);

I am no language lawyer, but .. given the issue of program observable effects (§5.1.2.3.12) and the "as is" implied rule that governs optimizations, how possibly could equality be stable over time?

[leni536]

Yeah, you are right. It seems to be that the problem is that we cram two standards into too few types. Additionally to float, double, and long double there could be optional iec559_single_t, iec559_double_t and iec559_extended_t (similarly to stdint.h integer types). The operations on variables of these types could be strictly iec559 conformant.