Date: Fri, 26 Feb 2016 17:01:29 +0000
| -----Original Message-----
| From: ub-bounces_at_[hidden] [mailto:ub-bounces_at_[hidden]] On Behalf
| Of Robert Haberlach
| Sent: Friday, February 26, 2016 4:13 AM
| To: ub_at_[hidden]
| Subject: [ub] launder and aliasing
|
| I apologize in advance if this was discussed before; I didn't check the entire
| archive. Consider
|
| static_assert(alignof(float) >= alignof(int) && sizeof(float) >= sizeof(int));
| int foo(float f) {
| return *std::launder(reinterpret_cast<int*>(&f)); }
|
| As it stands, invocation of foo is undefined, as the argument to launder is not
| pointing to an object of type int (or similar) within its lifetime, violating launder's
| requirement.
|
| launder is designed to inhibit address propagation analysis, which is the only
| concerning optimization. Moreover, as long as all usual conditions are met
| (alignment, size & trap values), this should be fine on any implementation. If so,
| can we make the above formally well-defined?
| Being able to use launder in such scenarios would render circumlocutions via
| memcpy superfluous.
|
| Robert
No, that is not good idea. We should have simple and safe primitives to access and set the object representation of a variable, but std::launder isn't it.
It is tempting to kill two birds with one stone, this one will blow off the entire planet.
-- Gaby
| From: ub-bounces_at_[hidden] [mailto:ub-bounces_at_[hidden]] On Behalf
| Of Robert Haberlach
| Sent: Friday, February 26, 2016 4:13 AM
| To: ub_at_[hidden]
| Subject: [ub] launder and aliasing
|
| I apologize in advance if this was discussed before; I didn't check the entire
| archive. Consider
|
| static_assert(alignof(float) >= alignof(int) && sizeof(float) >= sizeof(int));
| int foo(float f) {
| return *std::launder(reinterpret_cast<int*>(&f)); }
|
| As it stands, invocation of foo is undefined, as the argument to launder is not
| pointing to an object of type int (or similar) within its lifetime, violating launder's
| requirement.
|
| launder is designed to inhibit address propagation analysis, which is the only
| concerning optimization. Moreover, as long as all usual conditions are met
| (alignment, size & trap values), this should be fine on any implementation. If so,
| can we make the above formally well-defined?
| Being able to use launder in such scenarios would render circumlocutions via
| memcpy superfluous.
|
| Robert
No, that is not good idea. We should have simple and safe primitives to access and set the object representation of a variable, but std::launder isn't it.
It is tempting to kill two birds with one stone, this one will blow off the entire planet.
-- Gaby
Received on 2016-02-26 19:33:39