On 2015/04/29 09:29:36, Erik Corry wrote:
If you cast the pointer to unintptr_t then the subsequent downcast to
unsigned
(not int) will be well defined, not implementation defined.
It won't, in practice, make any difference to anything, because none of
the
compilers we care about define this 'wrong', and in any case the code
works
whatever result we calculate here.
Basically, I just wanted to raise the awareness regarding
implementation-defined/undefined behavior here (once again), especially
when it
is easy to avoid it, like in this case.
V8 is full of undefined behaviour. Tagged pointers, a JIT, Smi 'pointers'
etc.
Getting rid of this tiny piece of implementation defined behaviour in a
hash
code calculator seems like a waste of time to me.
*Undefined* behavior is a totally different beast and far from being
harmless.
We already had several hard-to-debug issues in the past because of this (fun
stuff like "this" being null because of our Smis etc., with the compiler
rightfully removing any "if (this == null)...", we saw sign checks being
removed
because of undefined shift behavior for signed values, etc.). For undefined
behavior the compiler can even choose to do different things at different
places, which doesn't exactly makes things easier. Furthermore, v8 is not
exactly a good citizen in the Chrome/google3 eco system, where people are
trying
to make UBSan happy. In a nutshell: We can possibly live with
implementation-defined behavior (if necessary), but we should remove
undefined
behavior, there is already a tracking bug for this:
https://code.google.com/p/v8/issues/detail?id=3770.
https://codereview.chromium.org/1105693002/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
