[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240725002335.GK10433@brightrain.aerifal.cx>
Date: Wed, 24 Jul 2024 20:23:35 -0400
From: Rich Felker <dalias@...c.org>
To: libc-coord@...ts.openwall.com
Subject: Re: #pragma STDC FENV_ACCESS ON
On Wed, Jul 24, 2024 at 05:48:16PM -0400, enh wrote:
> On Wed, Jul 24, 2024 at 2:31 PM Rich Felker <dalias@...c.org> wrote:
> >
> > On Thu, Jul 18, 2024 at 01:28:02PM -0400, enh wrote:
> > > has anyone else considered adding `#pragma STDC FENV_ACCESS ON` to
> > > <fenv.h>? expecting callers to realize they [might] have to do this
> > > [depending on their compiler and architecture] if they want to safely
> > > use most of the functions in <fenv.h> doesn't seem to be working out
> > > too well, even for libm authors...
> > >
> > > all the choices seem bad.
> >
> > That wouldn't even help because the compilers don't honor it.
>
> well, it's worse than that --- some need it, some don't. and even for
> a given compiler, it depends on the specific target architecture. (and
> i think MS' compilers have a different non-standard pragma instead.)
If the compiler doesn't honor it but has CFLAGS you can use that give
the equivalent semantics, then you can just use those and let the
pragma get ignore. That's what we do in musl -- we use the pragma
correctly, but since we don't expect the compiler will honor it, we
also use CFLAGS that should make it so the effects of the pragma are
always be in effect.
> > You need
> > nondefault CFLAGS instead. And even if it did help, it would just be
> > facilitating wrong/nonportable code. The reason nobody's using it is
>
> (it's used in musl's fmal() :-) )
The "it" was putting a hidden blanket "#pragma STDC FENV_ACCESS ON" in
the system fenv.h. We do not do that. We use it correctly at the
source level of files that needs it.
> > that the compilers ignore it (and IIRC at least at one point even
> > spammed warnings to that effect).
>
> clang will still complain if you use it for arm32 ... but requires it
> for x86-64.
Lovely...
> > Get the compilers fixed, teach them
> > to issue warnings when fenv functions are called without the pragma in
> > effect, and everything else will fix itself.
>
> lol, sure, but back in the real world where the compiler writers don't
> care about their users, and the standards committees don't care
> whether the language as standardized is actually usable or not...
>
> i think the strongest "meh, whatever, it's also not the libc owners'
> problem --- just leave users to deal with it" argument is probably
> that hardly anyone who doesn't own a libm actually cares about
> <fenv.h>. Android's arm32 <fenv.h> was completely broken (because
> someone had copy & pasted the BSD _mips_ inline assembler) for years,
> and afaik no user noticed --- i noticed when i was doing the arm64
> port and wrote the first test.
It's not that it's "not our problem". It's that we're not in a
position of being able to fix it.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
