Date: Thu, 17 Oct 2013 21:30:20 -0500
On 17 October 2013 19:18, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
>
> The implication in question is this:
>
> p == q => intptr_t(p) == intptr_t(q)
>
> where p and q are pointers. I am having trouble following how, even on
> such exotic architecture, the implication will be affected.
>
I can imagine that on a system concerned with security where
sizeof(intptr_t) > sizeof(p) random salt is added to the intptr_t
conversion which is removed when converting back to the pointer type.
> I suppose the other implication that is on the mind of many people but
> not being discussed is
>
> p != q => intptr_t(p) != intptr_t(q)
I'm not concerned about that, as p -> intptr_t(p) -> p has to result in a
matching pointer. I don't see how that is workable if the implication above
fails.
>
> The implication in question is this:
>
> p == q => intptr_t(p) == intptr_t(q)
>
> where p and q are pointers. I am having trouble following how, even on
> such exotic architecture, the implication will be affected.
>
I can imagine that on a system concerned with security where
sizeof(intptr_t) > sizeof(p) random salt is added to the intptr_t
conversion which is removed when converting back to the pointer type.
> I suppose the other implication that is on the mind of many people but
> not being discussed is
>
> p != q => intptr_t(p) != intptr_t(q)
I'm not concerned about that, as p -> intptr_t(p) -> p has to result in a
matching pointer. I don't see how that is workable if the implication above
fails.
-- Nevin ":-)" Liber <mailto:nevin_at_[hidden]> (847) 691-1404
Received on 2013-10-18 04:31:02