Last Comment Bug 677993 - GCC 4.6 Warning on 64-bit linux: "jsobjinlines.h:353:24: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]" (224 lines of output)
: GCC 4.6 Warning on 64-bit linux: "jsobjinlines.h:353:24: warning: cast to poi...
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86_64 Linux
-- normal (vote)
: mozilla8
Assigned To: Daniel Holbert [:dholbert]
: Jason Orendorff [:jorendorff]
Depends on:
Blocks: buildwarning 584917
  Show dependency treegraph
Reported: 2011-08-10 12:07 PDT by Daniel Holbert [:dholbert]
Modified: 2011-08-14 04:55 PDT (History)
3 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

the 224 lines of warning output (21.02 KB, text/plain)
2011-08-10 12:07 PDT, Daniel Holbert [:dholbert]
no flags Details
fix: add size_t cast (743 bytes, patch)
2011-08-10 12:17 PDT, Daniel Holbert [:dholbert]
bhackett1024: review+
Details | Diff | Splinter Review

Description User image Daniel Holbert [:dholbert] 2011-08-10 12:07:06 PDT
Created attachment 552163 [details]
the 224 lines of warning output

I get 224 lines of build warning spam resulting from this warning:
> jsobjinlines.h: In member function ‘void JSObject::setArrayLength(uint32)’:
> jsobjinlines.h:353:24: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]

(See attached log of the warnings.)

The code in question is:
> 350 JSObject::setArrayLength(uint32 length)
> 351 {
> 352     JS_ASSERT(isArray());
> 353     setPrivate((void*) length);
> 354 }

If we simply convert |length| to a long (or unsigned long if you like) just before the void* cast, I think that should fix this.
Comment 1 User image Daniel Holbert [:dholbert] 2011-08-10 12:17:39 PDT
Created attachment 552166 [details] [diff] [review]
fix: add size_t cast

er, I meant s/long/size_t/ in previous comment.  (dbaron tells me that "long" isn't guaranteed to be 64-bit on 64-bit systems -- e.g. on win64, a long is 32-bit -- whereas size_t is (more?) guaranteed to be the same size as a pointer.)

Tagging bhackett for review, since he added this line in bug 584917.

(Note that I'm assuming the GCC warning is innocuous -- it seems like we're using the void*-cast to just set a generic payload value, rather than actually depending on it being a sane pointer in this case.)
Comment 2 User image Brian Hackett (:bhackett) 2011-08-10 12:21:12 PDT
Comment on attachment 552166 [details] [diff] [review]
fix: add size_t cast

Yeah, this warning is innocuous.  setPrivate takes a void* but can hold any word-sized payload, and setArrayLength takes a uint32 because that is the range for an array length permitted by the JS language.
Comment 3 User image Daniel Holbert [:dholbert] 2011-08-10 12:40:42 PDT
Great -- thanks for the quick review!

I'll land this in the next day or so.
Comment 4 User image Daniel Holbert [:dholbert] 2011-08-11 11:48:59 PDT
Comment 5 User image Matt Brubeck (:mbrubeck) 2011-08-12 08:11:00 PDT
Comment 6 User image Jeff Walden [:Waldo] (remove +bmo to email) 2011-08-12 08:52:23 PDT
At risk of utter pedantry, the _u_nsigned _int_eger _p_oin_t_e_r_-sized type is uintptr_t.  :-)  But, come to think of it, there might actually be some crazy architecture which will notice this.  I think someone filed a bug along those lines in the last few months, actually.  rs=me if someone feels motivated to change this, in the absence of someone actively complaining about it.
Comment 7 User image Daniel Holbert [:dholbert] 2011-08-12 11:34:19 PDT says Waldo is right, & size_t isn't technically what we want here.

Pushed a followup to fix both setArrayLength() (the function touched by the earlier patch) and getArrayLength() (which also used a void*<-->size_t cast, and hence also benefits from Waldo's insight as well):
Comment 8 User image Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-08-14 04:55:19 PDT

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