Last Comment Bug 726236 - IonMonkey: give actualOffset a sane type
: IonMonkey: give actualOffset a sane type
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: unspecified
: ARM Linux
-- normal (vote)
: ---
Assigned To: Marty Rosenberg [:mjrosenb]
: Jason Orendorff [:jorendorff]
Depends on:
  Show dependency treegraph
Reported: 2012-02-10 17:17 PST by Marty Rosenberg [:mjrosenb]
Modified: 2012-02-27 18:59 PST (History)
2 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

/home/mrosenberg/patches/fix_actualOffset-r1.patch (7.99 KB, patch)
2012-02-20 00:07 PST, Marty Rosenberg [:mjrosenb]
dvander: review+
Details | Diff | Splinter Review

Description User image Marty Rosenberg [:mjrosenb] 2012-02-10 17:17:08 PST
It currently takes a uint8* and returns a ptrdiff_t, which makes no sense, since it is dealing with offsets.  This needs to be remedied.
Comment 1 User image Marty Rosenberg [:mjrosenb] 2012-02-20 00:07:04 PST
Created attachment 598786 [details] [diff] [review]

There is a bit of hariness with the repoint functions on amd64, since the "offset" that needs to be fixed up is a pointer, not a narrower value.  Even though there is an explicit check that the value fits into the 32 bit range, gcc complains about losing precision in the uint8* -> uint32 cast, so I've casted it to long, which then gets downcasted to uint32 without any errors.
Comment 2 User image David Anderson [:dvander] 2012-02-21 16:33:48 PST
Comment on attachment 598786 [details] [diff] [review]

Review of attachment 598786 [details] [diff] [review]:

Thanks for doing this, nice to see all these casts go away.

::: js/src/ion/IonCaches.cpp
@@ +78,5 @@
> +     if (masm != NULL) {
> +#ifdef JS_CPU_X64
> +        JS_ASSERT((uint64_t)raw_ <= UINT32_MAX);
> +#endif
> +        new_off = masm->actualOffset((unsigned long)raw_);

Cast to uintptr_t or uint32 or something here (and above) - long is different on posix vs. win64.
Comment 3 User image Emanuel Hoogeveen [:ehoogeveen] 2012-02-22 03:39:40 PST
'unsigned' (short for 'unsigned int') doesn't have that problem as far as I'm aware, but the language gives no guarantees. 'uintptr_t' is guaranteed to be the same size as a pointer, so if you just explicitly want a 32-bit integer 'uint32_t' makes the most sense.
Comment 4 User image Marty Rosenberg [:mjrosenb] 2012-02-27 18:59:18 PST

Note You need to log in before you can comment on or make changes to this bug.