On 2020-10-27 07:58 +0100, Marc Nieper-Wißkirchen wrote:
> Am Di., 27. Okt. 2020 um 02:18 Uhr schrieb Wolfgang Corcoran-Mathe
> <xxxxxx@sigwinch.xyz>:
> >
> > On 2020-10-26 18:18 -0400, John Cowan wrote:
> > > On Mon, Oct 26, 2020 at 2:07 PM Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz>
> > > wrote:
> > >
> > > Would it be sufficient to provide C versions of
> > > > nan-quiet?, nan-negative?, etc., operating on doubles?
> > > >
> > >
> > > That's exactly what I had in mind.  Create a union type in C that can be
> > > either a double or a uint64, put in the double, get out the uint64, and
> > > bit-twiddle it, probably 10-15 lines of code.
> >
> > This would be undefined behavior in C89, but, after a lot of
>
> Is it undefined in C89? I think it is just implementation-defined behavior.

You're right, it's implementation-defined.

> > > If the member used to access the contents of a union object is not
> > > the same as the member last used to store a value in the object, the
> > > appropriate part of the object representation of the value is
> > > reinterpreted as an object representation in the new type as
> > > described in 6.2.6 (a process sometimes called "type punning").
> > > This might be a trap representation.
>
> "Reinterpreted as an object ..." is again implementation-defined,
> isn't it? Is there a way to find out how an IEEE double is mapped to
> an array of chars?

Yes, it seems so.  (With ISO C, there's always more.  I'm not really
sure now whether their adding that footnote in the 2007 draft
clarified anything.)

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"To a wise man, the whole earth is open, because the true country of a
virtuous soul is the entire universe." --Democritus