Re: [lmi] fesetround() requirements and guarantees

[Vadim Zeitlin]

On Fri, 13 May 2022 07:38:06 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 5/12/22 14:49, Vadim Zeitlin wrote:
GC> > On Thu, 12 May 2022 09:06:42 +0000 Greg Chicares 
<gchicares@sbcglobal.net> wrote:
[...]
GC> > GC>  - How often should this be called? C++20 [cfenv.syn] specifies that 
the
GC> > GC>    floating-point environment has "thread storage duration" and that
GC> > GC>    child threads inherit the calling thread's environment, so 
shouldn't
GC> > GC>    it be sufficient to set it OAOO, at program startup? C++20 doesn't
GC> > GC>    seem to require that the compiler library restore the original 
state
GC> > GC>    when a library function changes it, AFAICT; can they really have
GC> > GC>    left that as a QOI issue?
GC> > 
GC> >  IMO there should be no reason to call it at all (which renders the
GC> > question above moot too, as a nice side effect) because FE_TONEAREST is
GC> > the default rounding mode anyhow, but if we do want to call it, there
GC> > should be no reason to call it more than once. I know that you were 
worried
GC> > about some rogue DLL, possibly loaded as an Explorer extension when using
GC> > the file open dialog, could change the process rounding mode but this kind
GC> > of things shouldn't happen accidentally any more -- and any DLL that wants
GC> > to intentionally skew lmi calculation results could still do it in a 
number
GC> > of creative ways not relying on the rounding mode.
GC> I'm more concerned about sloppiness than malice.

 Yes, I understand this, but IME random changes to the rounding mode just
don't happen. Of course, I can't guarantee that they don't and I don't know
of any portable way to ensure this, but perhaps we could just add checks
for fegetround() == FE_TONEAREST before and after any critical parts of
code?

 Regards,
VZ

pgpcgnUawKE0d.pgp
Description: PGP signature