Re: [lmi] fesetround() requirements and guarantees

[Greg Chicares]

On 5/12/22 14:49, Vadim Zeitlin wrote:
> On Thu, 12 May 2022 09:06:42 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:

[...checking the return code of fesetround()...]

[...snip discussion of glibc and mingw implementations...]
>  Also, while I don't have source code for the MSVC implementation, it seems
> to do something very similar from looking at its assembly code but,
> interestingly, it ends by calling fegetround() and checking that the
> returned value is equal to the one we just set and returns 1 if they
> differ. AFAICS this still means that it always returns 0 because I don't
> think setting the control word can fail but it's still a bit curious that
> they decided they needed this check.

This is only idle speculation, but where the free implementations do:
 - check argument; return nonzero if invalid
 - else do FLDCW and LDMXCSR
they might instead do this:
 - FLDCW and LDMXCSR
 - read back using F[N]STCW and SMXCSR; return nonzero if they don't
     have the expected values.

The C++ committee could have provided a small set of functions
(one for each rounding direction) like:
  void fe_round_near() noexcept; // as if fesetround(FE_TONEAREST)
the advantages being "void" and "noexcept". I'd call that a missed
opportunity.

> GC>  - How often should this be called? C++20 [cfenv.syn] specifies that the
> GC>    floating-point environment has "thread storage duration" and that
> GC>    child threads inherit the calling thread's environment, so shouldn't
> GC>    it be sufficient to set it OAOO, at program startup? C++20 doesn't
> GC>    seem to require that the compiler library restore the original state
> GC>    when a library function changes it, AFAICT; can they really have
> GC>    left that as a QOI issue?
> 
>  IMO there should be no reason to call it at all (which renders the
> question above moot too, as a nice side effect) because FE_TONEAREST is
> the default rounding mode anyhow, but if we do want to call it, there
> should be no reason to call it more than once. I know that you were worried
> about some rogue DLL, possibly loaded as an Explorer extension when using
> the file open dialog, could change the process rounding mode but this kind
> of things shouldn't happen accidentally any more -- and any DLL that wants
> to intentionally skew lmi calculation results could still do it in a number
> of creative ways not relying on the rounding mode.
I'm more concerned about sloppiness than malice. I haven't been able
to find a requirement in the C or C++ Standard that library functions
other than fesetround() restore the rounding mode on exit.
C99 [F.9.3.12/2] gives a reference implementation of modf() that
does explicitly restore it, and I suppose that's normative; but
for floor() [F.9.6.2/2], there's no such explicit prescription.
I've seen QOI issues with the mingw standard library in the past,
so I do worry stuff like this.