0

As per the C99 standard:

6.3.1.8.2: The values of floating operands and of the results of floating expressions may be represented in greater precision and range than that required by the type; the types are not changed thereby.52)>

However, outside the scope of Annex F, we have:

5.2.4.2.2.7: The values of operations with floating operands and values subject to the usual arithmetic conversions and of floating constants are evaluated to a format whose range and precision may be greater than required by the type. The use of evaluation formats is characterized by the implementation-defined value of FLT_EVAL_METHOD:19)

Where FLT_EVAL_METHOD can be:

  • -1: indeterminable
  • 0: evaluate all operations and constants just to the range and precision of the type
  • 1: evaluate operations and constants of type float and double to the range and precision of the double type, evaluate long double operations and constants to the range and precision of the long double type
  • 2: evaluate all operations and constants to the range and precision of the long double type.

As such, for a conforming implementation, does FLT_EVAL_METHOD == [0, 1, 2] overrule 6.3.1.8.2? That is, explicit casts and/or type assignments are not needed to enforce a given width?

chux - Reinstate Monica
  • 143,097
  • 13
  • 135
  • 256
Kay
  • 745
  • 5
  • 15
  • 1
    No. See the note: http://en.cppreference.com/w/cpp/types/climits/FLT_EVAL_METHOD – Eugene Sh. May 15 '18 at 18:29
  • 1
    @EugeneSh. Thanks for the response. Since it's a C question, the relevant documentation is *C99:6.5.8*. My obvious follow-up is, what if **FP_CONTRACT** is off – Kay May 15 '18 at 18:38
  • Do you really want C 1999 and not C 2011? – Eric Postpischil May 15 '18 at 19:13
  • There's an equivalent link for the C standard: http://en.cppreference.com/w/c/types/limits/FLT_EVAL_METHOD – Christian Gibbons May 15 '18 at 19:14
  • 1
    @EricPostpischil Yes, C99. It's the only version (at least partially) supported by MSVC. – Kay May 15 '18 at 19:25
  • @ChristianGibbons Thanks for the link! (As a nitpick, it isn't the *standard*, see my above comment :P) – Kay May 15 '18 at 19:27
  • I think ffrom memory that FLT_EVAL_METHOD ensures that any variable types are honoured, even if they are optimised, but CONTRACT ensures that every step of an expression that does not have explicit variables and casts honours the FLT_EVAL_METHOD, but to be honest, if it matters that much perhaps FP is the wrong medium for you? – Gem Taylor May 15 '18 at 19:41
  • I'm not sure why you want `FLT_EVAL_METHOD` to “overrule” 6.3.1.8.2… 6.3.1.8.2 is reminding you that `FLT_EVAL_METHOD` exists and influences the effective precision of floating-point expressions. – Pascal Cuoq May 15 '18 at 20:43
  • @GemTaylor It only matters so far in that I'm curious and want to be able to reason about the code. – Kay May 15 '18 at 20:55
  • @PascalCuoq It's not that I *want* it to overrule; I just want to know what happens in this case. I don't think *6.3.1.8.2* is meant to remind - it predates `FLT_EVAL_METHOD` to C90 IIRC. – Kay May 15 '18 at 20:57
  • 2
    I do not think looking to the C standard for information on how MSVC will behave is a reliable idea. – Eric Postpischil May 15 '18 at 20:58
  • @Kay In C90, authors of the standard already knew that some computers would only be able to compute at some precision higher than that of some floating-point types, but left the details as a vague allusion. They wrote what remained in C99 as 6.3.1.8.2. In C99, someone with taste inside the committee must have convinced everyone that it would be useful to have more predictable semantics for what exactly happened with that excess precision that had to sometimes happen, so they wrote the description of `FLT_EVAL_METHOD` (also `FP_CONTRACT`). – Pascal Cuoq May 15 '18 at 21:18
  • 1
    @Kay My point is, these two parts of the standard do not contradict each other, so it's a bit strange to say that one “overrules” the other. If you are interested in the details of what happens, it's 5.2.4.2.2.7 that you should look at (and also the `FP_CONTRACT` setting, although that is basically not implemented in the form described by the standard by any compiler in common use). – Pascal Cuoq May 15 '18 at 21:26
  • @EricPostpischil Not the intention. Intention (maybe chasing a unicorn), would be to have C99-defined behaviour, which (hopefully) MSVC (along with the other compilers I need to support), as part of a conforming implementation, would uphold. I mean - that's the point of having a *standard* – Kay May 15 '18 at 23:20
  • 1
    @PascalCuoq Yep, I agree with what you are saying. Perhaps *"overrules"* was a bad word to use; I should be more careful when describing technical standards, where such wording is clearly important :P Perhaps I should restate as: `FLT_EVAL_METHOD`, when not -1, provides the predictable semantics that 5.2.4.2.2.7 leaves vague. – Kay May 15 '18 at 23:24
  • 1
    @Kay: My point is the standard is irrelevant if the compiler does not claim or attempt to conform to it (to a greater or lesser degree). The fact that a standard exists does not mean any particular compiler conforms to it, and [Microsoft largely neglects the C standard](https://stackoverflow.com/questions/146381/visual-studio-support-for-new-c-c-standards). MSVC has a (somewhat) C++ compiler with some C features. You should not expect it to obey fine points of standard C semantics. – Eric Postpischil May 15 '18 at 23:27
  • @EricPostpischil That post is quite old. MSVC, since VS2013 and VS2015, have much better C99 support (https://blogs.msdn.microsoft.com/vcblog/2013/07/19/c99-library-support-in-visual-studio-2013/, https://msdn.microsoft.com/en-us/library/hh409293(v=vs.140).aspx#BK_CRT). That being said, I will heed your warning regarding compilers. I've actually recently discovered many mainstream C compilers don't *actually* support the full C99 standard, even if they defines the various macros claiming they do (yet, will take advantage of every possible vagueness in the std to gain some minor optimization) – Kay May 18 '18 at 00:35

0 Answers0