Date: Thu, 25 Jul 2013 14:40:25 -0700
On 7/25/13, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
> Lawrence Crowl <Lawrence_at_[hidden]> writes:
>
> | On 7/25/13, Howard Hinnant <howard.hinnant_at_[hidden]> wrote:
> | > It was this SO question that started this thread:
> | >
> | > http://stackoverflow.com/q/17789928/576911
> | >
> | > I'm curious: The accepted answer uses memcpy and the claim is that this
> is
> | > a correct answer to the question. That is it does not exhibit
> undefined
> | > behavior. My current understanding is that I agree with this answer.
> But I
> | > wanted to check here. Do people here agree that:
> | >
> | > http://stackoverflow.com/a/17790026/576911
> | >
> | > does not break the aliasing rules, or otherwise invoke undefined
> behavior?
> |
> | I believe so.
>
> I can't find the rule (in the standards) that the memcpy() into i
> constitutes an initialization.
It is trivial assignment, and initialization is unnecessary because it
is trivial. We could probably be clearer.
> One also needs something for the
> memcpy() back into x, saying that does not yield a trap representation,
> which would otherwise lead to undefined behaviour in the update:
>
> x = x*(1.5f - xhalf*x*x);
But at that point aren't we already platform dependent?
I.e. dealing with the representation?
> Lawrence Crowl <Lawrence_at_[hidden]> writes:
>
> | On 7/25/13, Howard Hinnant <howard.hinnant_at_[hidden]> wrote:
> | > It was this SO question that started this thread:
> | >
> | > http://stackoverflow.com/q/17789928/576911
> | >
> | > I'm curious: The accepted answer uses memcpy and the claim is that this
> is
> | > a correct answer to the question. That is it does not exhibit
> undefined
> | > behavior. My current understanding is that I agree with this answer.
> But I
> | > wanted to check here. Do people here agree that:
> | >
> | > http://stackoverflow.com/a/17790026/576911
> | >
> | > does not break the aliasing rules, or otherwise invoke undefined
> behavior?
> |
> | I believe so.
>
> I can't find the rule (in the standards) that the memcpy() into i
> constitutes an initialization.
It is trivial assignment, and initialization is unnecessary because it
is trivial. We could probably be clearer.
> One also needs something for the
> memcpy() back into x, saying that does not yield a trap representation,
> which would otherwise lead to undefined behaviour in the update:
>
> x = x*(1.5f - xhalf*x*x);
But at that point aren't we already platform dependent?
I.e. dealing with the representation?
-- Lawrence Crowl
Received on 2013-07-25 23:40:26