0

Follow-up question for Why conversion (unsigned long long)DBL_MAX (or FLT_MAX) causes raising of FE_INEXACT as well?.

Is raising of unexpected exception (FE_INEXACT) considered as an implementation defect?

Notes:

  1. User @Nate Eldredge confirms that on AArch64 FE_INEXACT is not raised.
  2. All the hardware powered by Infineon TriCore does not raise FE_INEXACT, because the condition to raise FE_INEXACT is inexact && ! invalid. I.e. it is not possible to have both FE_INEXACT and FE_INVALID raised.

Reason of the question: need to precisely interpret / classify / categorize this case.

pmor
  • 5,392
  • 4
  • 17
  • 36
  • One of the answers in the other question says this is undefined behavior. That means anything is permitted, so no behavior could be considered a defect. – Barmar Mar 04 '21 at 22:10
  • 1
    Is it considered a defect by whom? – Eric Postpischil Mar 04 '21 at 23:21
  • By the end user. The end user expects only `FE_INVALID`. However, the implementation raises `FE_INEXACT` as well. Does IEEE 754 permit raising of `FE_INEXACT` in addition to required `FE_INVALID`? For example, one my colleague does not see in C / IEEE 754 any direct prohibitions to raise `FE_INEXACT` in this case. What is your view? – pmor Mar 05 '21 at 21:26
  • @Barmar _When the C standard does not define a behavior, the behavior may be defined, partially or completely, by other standards_ (https://stackoverflow.com/questions/65106621/fp-invalid-operation-contradiction-between-c-ub-and-ieee-754-wdb/65107366#65107366). In this case it is IEEE 754. Also (from C standard): _Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment_. – pmor Mar 05 '21 at 21:28
  • 1
    This sounds more like a quality of implementation issue. – Barmar Mar 05 '21 at 21:30

0 Answers0