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.

> searching, it does seem that type-punning through unions is valid in
> C99 (and C11, allegedly; I don't have a copy of that standard).
> Footnote 82 to section 6.5.2.3 (present in more recent drafts of the C99
> standard) clarifies this (somewhat):

> > 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?