RetainPtr.h:318:20: error: implicit conversion loses integer precision: 'CFHashCode' (aka 'unsigned long') to 'unsigned int' [-Werror,-Wshorten-64-to-32] return CFHash(o.get()); ~~~~~~ ^~~~~~~~~~~~~~~ CFHash() returns a CFHashCode, which is typedef-ed to 'unsigned long', which is 4 bytes on 32-bit architectures (which matches 'unsigned'), but 8 bytes on 64-bit architectures. I see two possible fixes here: 1. Use a static_cast<uint32_t>() operator to just take the lower 4 bytes for the hash code. This is what is implicitly happening now. 2. Use static_cast<uint64_t>() with WTF::intHash() to generate a new 4-byte hash code using the 8-byte CFHashCode. Thoughts?
Created attachment 199310 [details] Patch v1
Comment on attachment 199310 [details] Patch v1 View in context: https://bugs.webkit.org/attachment.cgi?id=199310&action=review > Source/WTF/wtf/RetainPtr.h:318 > + return static_cast<uint32_t>(CFHash(o.get())); Wouldn’t it be better to cast to the function's return type (unsigned)?
(In reply to comment #2) > (From update of attachment 199310 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=199310&action=review > > > Source/WTF/wtf/RetainPtr.h:318 > > + return static_cast<uint32_t>(CFHash(o.get())); > > Wouldn’t it be better to cast to the function's return type (unsigned)? Yes.
Created attachment 199311 [details] Patch v2
Comment on attachment 199311 [details] Patch v2 Clearing flags on attachment: 199311 Committed r148979: <http://trac.webkit.org/changeset/148979>
All reviewed patches have been landed. Closing bug.