Closed Bug 726236 Opened 12 years ago Closed 12 years ago

IonMonkey: give actualOffset a sane type

Categories

(Core :: JavaScript Engine, defect)

ARM
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: mjrosenb, Assigned: mjrosenb)

Details

Attachments

(1 file)

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.
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.
Attachment #598786 - Flags: review?(dvander)
Comment on attachment 598786 [details] [diff] [review]
/home/mrosenberg/patches/fix_actualOffset-r1.patch

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.
Attachment #598786 - Flags: review?(dvander) → review+
'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.
landed: http://hg.mozilla.org/projects/ionmonkey/rev/436027e218b3
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.