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 jos...@codesourcery.com