On 2015/04/29 15:03:35, titzer wrote:
On 2015/04/29 03:43:10, Benedikt Meurer wrote:
> On 2015/04/27 07:57:51, titzer wrote:
> >
https://codereview.chromium.org/1105693002/diff/1/src/heap/identity-map.h
> > File src/heap/identity-map.h (right):
> >
> >
>
https://codereview.chromium.org/1105693002/diff/1/src/heap/identity-map.h#newcode68
> > src/heap/identity-map.h:68: return static_cast<int>((raw_address >>
11) ^
> > raw_address);
> > On 2015/04/27 06:26:47, Sven Panne wrote:
> > > On 2015/04/27 04:04:17, Benedikt Meurer wrote:
> > > > Down casting to int looks wrong here. How about using uintptr_t
here?
Or
> > even
> > > > better use size_t?
> > >
> > > Veto from the *San sheriff, too: This line is causing
implementation-defined
> > > behavior...
> >
> > This is the computation of a hashcode from an address and is
inherently
> > implementation-dependent. This is not _undefined_ behavior.
>
> I think you're talking about different implementation-defined behaviors:
There's
> (a) the cast from a pointer to an integral type, which is _desired_
> implementation-defined behavior, and (b) the down cast to int, which is
> _undesired_ implementation-defined behavior. And I think Sven was only
talking
> about (b).
We always mask the hash before going to search the table, so I think the
implementation-defined handling of the sign bit is a non-issue here.
I think it all comes down to the fact that int is simply the wrong type
here,
and it doesn't buy you anything since you are just using it as an array
index,
so you could as well just use the correct type instead, which is probably
size_t.
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.
