Bug 115047 – RetainPtr.h should compile with -Wshorten-64-to-32

• Status: RESOLVED
• Resolution: FIXED
• Component: Web Template Framework

[David Kilzer (:ddkilzer)]

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?

[David Kilzer (:ddkilzer)]

Created attachment 199310 [details]
Patch v1

[Anders Carlsson]

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)?

[David Kilzer (:ddkilzer)]

(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.

[David Kilzer (:ddkilzer)]

Created attachment 199311 [details]
Patch v2

[WebKit Commit Bot]

Comment on attachment 199311 [details]
Patch v2

Clearing flags on attachment: 199311

Committed r148979: <http://trac.webkit.org/changeset/148979>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.