This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: _Bool and trap representations
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Alexander Cherepanov <ch3root at openwall dot com>
- Cc: Martin Sebor <msebor at gmail dot com>, <gcc at gcc dot gnu dot org>
- Date: Mon, 13 Jun 2016 19:51:02 +0000
- Subject: Re: _Bool and trap representations
- Authentication-results: sourceware.org; auth=none
- References: <5757BCD9 dot 9070407 at openwall dot com> <57582D90 dot 1080000 at gmail dot com> <575F0328 dot 7070905 at openwall dot com>
On Mon, 13 Jun 2016, Alexander Cherepanov wrote:
> Thanks for the info. IMHO this part of DR 260 has even more serious
> consequences than the part about pointer provenance. It effectively prohibits
> manual byte-by-byte (or any non-atomic) copying of objects for types like long
> double. If an implementation decides to normalize a value in a variable during
> copying it will see an inconsistent representation, e.g. a trap
> representation. It's a sure way to get total garbage. I don't know if allowing
No, that's not the case; even if representations can change during
byte-by-byte copying, such copying of long double values is *still* safe.
All long double values for x86 long double have exactly one valid
representation in the value bits, and if the padding bits change during
copying it doesn't matter; it's only representations that are already trap
representations (unnormals, pseudo-* etc.) that might be interpreted
inconsistently.
Likewise for IBM long double; the only cases of more than one
representation for a value are (a) a zero low part might have either sign
(in which case an arbitrary choice of bytes from the two representations
still gives a valid representation of the same value) and (b) the low part
of a NaN is of no significance.
--
Joseph S. Myers
joseph@codesourcery.com