Lawrence Crowl <Lawrence_at_[hidden]> writes:

| 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.

I can't find the rule for that interpretation. The closest I can come
to is 3.9/3, but that paragraph requires copying from an object of the
same type:

  # For any trivially copyable type T, if two pointers to T point to
  # distinct T objects obj1 and obj2, where neither obj1 nor obj2 is a
  # base-class subobject, if the underlying bytes (1.7) making up obj1 are
  # copied into obj2,41 obj2 shall subsequently hold the same value as obj1.

| > 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?

I can't find rules that cover that, or that would make it platform dependent.

-- Gaby