Date: Thu, 25 Jul 2013 17:20:01 -0500
Ion Gaztañaga <igaztanaga_at_[hidden]> writes:
| El 25/07/2013 17:45, Gabriel Dos Reis escribió:
| > If that analysis is correct, I would welcome a rule in the language that
| > says that memcpy() into an object of type that admits no trap
| > representation is equivalent to initialization with value obtained from
| > appropriate interpretation of the value representation bits of the
| > "initializing byte" sequence.
|
| Why can't we memcpy to a type that admits a trap representation (say, a
| float with a signaling NaN value)?
I didn't say you can't or you shouldn't.
The issue is: given the program (or program fragment) does the standard
text cover the behavior? I am unable to find the rules that would
define the behavior.
| If we know about that representation
| is in our system, the programmer should be responsible for not creating
| such bit pattern before copying it to the destination.
just as the programmer is responsible for writing correct programs, or
at least for not breaking the language rules :-)
| Couldn't we write:
|
| float f_uninitialized;
| std::memcpy(&f_uninitialized, &i32, sizeof(i32));
|
| ?
The issue is what does the standard text has to say about the behavior of
that program if f_uninitialized is subject to read access or part of an
arithmetic expression. Like I said, I have not been able to find the
rules that govern this. If there is none, then we might want to do
something about it.
-- Gaby
| El 25/07/2013 17:45, Gabriel Dos Reis escribió:
| > If that analysis is correct, I would welcome a rule in the language that
| > says that memcpy() into an object of type that admits no trap
| > representation is equivalent to initialization with value obtained from
| > appropriate interpretation of the value representation bits of the
| > "initializing byte" sequence.
|
| Why can't we memcpy to a type that admits a trap representation (say, a
| float with a signaling NaN value)?
I didn't say you can't or you shouldn't.
The issue is: given the program (or program fragment) does the standard
text cover the behavior? I am unable to find the rules that would
define the behavior.
| If we know about that representation
| is in our system, the programmer should be responsible for not creating
| such bit pattern before copying it to the destination.
just as the programmer is responsible for writing correct programs, or
at least for not breaking the language rules :-)
| Couldn't we write:
|
| float f_uninitialized;
| std::memcpy(&f_uninitialized, &i32, sizeof(i32));
|
| ?
The issue is what does the standard text has to say about the behavior of
that program if f_uninitialized is subject to read access or part of an
arithmetic expression. Like I said, I have not been able to find the
rules that govern this. If there is none, then we might want to do
something about it.
-- Gaby
Received on 2013-07-26 00:20:18