Fixes the following warnings with -Wshorten-64-to-32: StringImpl.h:317:25: error: implicit conversion loses integer precision: 'uintptr_t' (aka 'unsigned long') to 'unsigned int' [-Werror,-Wshorten-64-to-32] unsigned hash = reinterpret_cast<uintptr_t>(this); ~~~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Created attachment 199053 [details] Patch v1
Comment on attachment 199053 [details] Patch v1 View in context: https://bugs.webkit.org/attachment.cgi?id=199053&action=review > Source/WTF/wtf/text/StringImpl.h:316 > - unsigned hash = reinterpret_cast<uintptr_t>(this); > + unsigned hash = static_cast<uint32_t>(reinterpret_cast<uintptr_t>(this)); This is a silly approach to creating the hash. For example, the low bits will always be due to alignment zero. I suggest we use a random number instead. Code change is OK, but code is dumb.
The commit-queue encountered the following flaky tests while processing attachment 199053 [details]: platform/mac/editing/deleting/deletionUI-single-instance.html bug 114181 (author: rniwa@webkit.org) transitions/color-transition-rounding.html bug 114182 (author: simon.fraser@apple.com) transitions/cubic-bezier-overflow-svg-length.html bug 114183 (author: peter@chromium.org) transitions/interrupt-zero-duration.html bug 114184 (authors: cmarrin@apple.com, rniwa@webkit.org, and simon.fraser@apple.com) transitions/multiple-background-transitions.html bug 114185 (author: simon.fraser@apple.com) transitions/cubic-bezier-overflow-color.html bug 114186 (author: peter@chromium.org) transitions/multiple-shadow-transitions.html bug 114187 (author: simon.fraser@apple.com) transitions/mismatched-shadow-transitions.html bug 114188 (author: simon.fraser@apple.com) transitions/color-transition-all.html bug 114189 (authors: ossy@webkit.org and simon.fraser@apple.com) transitions/negative-delay.html bug 114190 (author: simon.fraser@apple.com) transitions/cubic-bezier-overflow-shadow.html bug 114191 (author: peter@chromium.org) transitions/min-max-width-height-transitions.html bug 114192 (author: simon.fraser@apple.com) transitions/cancel-transition.html bug 114193 (authors: ojan@chromium.org, rniwa@webkit.org, and simon.fraser@apple.com) transitions/border-radius-transition.html bug 114194 (author: simon.fraser@apple.com) transitions/flex-transitions.html bug 114195 (author: tony@chromium.org) transitions/mixed-type.html bug 114196 (author: mikelawther@chromium.org) transitions/multiple-mask-transitions.html bug 114197 (author: simon.fraser@apple.com) transitions/color-transition-premultiplied.html bug 114198 (author: simon.fraser@apple.com) transitions/mismatched-shadow-styles.html bug 114199 (author: simon.fraser@apple.com) transitions/mask-transitions.html bug 114200 (authors: ojan@chromium.org, oliver@apple.com, and simon.fraser@apple.com) transitions/cubic-bezier-overflow-length.html bug 114201 (author: peter@chromium.org) transitions/multiple-background-size-transitions.html bug 114202 (authors: mitz@webkit.org and simon.fraser@apple.com) transitions/clip-transition.html bug 114203 (authors: dglazkov@chromium.org and simon.fraser@apple.com) transitions/cubic-bezier-overflow-transform.html bug 114204 (author: peter@chromium.org) transitions/shorthand-border-transitions.html bug 114205 (authors: ojan@chromium.org and simon.fraser@apple.com) transitions/interrupted-accelerated-transition.html bug 56242 (authors: rniwa@webkit.org, simon.fraser@apple.com, and tonyg@chromium.org) transitions/background-transitions.html bug 114206 (author: simon.fraser@apple.com) http/tests/security/cookies/third-party-cookie-blocking-user-action.html bug 114511 (authors: ap@webkit.org, jochen@chromium.org, and rniwa@webkit.org) http/tests/security/mixedContent/redirect-https-to-http-iframe-in-main-frame.html bug 114208 (authors: abarth@webkit.org and rniwa@webkit.org) fast/loader/javascript-url-in-object.html bug 114210 (authors: rniwa@webkit.org and sam@webkit.org) The commit-queue is continuing to process your patch.
Comment on attachment 199053 [details] Patch v1 Clearing flags on attachment: 199053 Committed r148900: <http://trac.webkit.org/changeset/148900>
All reviewed patches have been landed. Closing bug.
(In reply to comment #2) > (From update of attachment 199053 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=199053&action=review > > > Source/WTF/wtf/text/StringImpl.h:316 > > - unsigned hash = reinterpret_cast<uintptr_t>(this); > > + unsigned hash = static_cast<uint32_t>(reinterpret_cast<uintptr_t>(this)); > > This is a silly approach to creating the hash. For example, the low bits will always be due to alignment zero. I suggest we use a random number instead. > > Code change is OK, but code is dumb. Should we use WTF::intHash(uint32_t) on 32-bit platforms and WTF::intHas(uint64_t) on 64-bit platforms instead?
(In reply to comment #6) > (In reply to comment #2) > > (From update of attachment 199053 [details] [details]) > > View in context: https://bugs.webkit.org/attachment.cgi?id=199053&action=review > > > > > Source/WTF/wtf/text/StringImpl.h:316 > > > - unsigned hash = reinterpret_cast<uintptr_t>(this); > > > + unsigned hash = static_cast<uint32_t>(reinterpret_cast<uintptr_t>(this)); > > > > This is a silly approach to creating the hash. For example, the low bits will always be due to alignment zero. I suggest we use a random number instead. > > > > Code change is OK, but code is dumb. > > Should we use WTF::intHash(uint32_t) on 32-bit platforms and WTF::intHas(uint64_t) on 64-bit platforms instead? The only property needed for that hash is it should never equals the hash of emptyString(). We could basically use a constant here. Any number !m hash(empty()) has the same theoretical chances of conflicts. I have been trying to kill this constructor every now and then :)
(In reply to comment #7) > The only property needed for that hash is it should never equals the hash of emptyString(). Maybe (hash(emptyString()) ^ 0x100) would work?
(In reply to comment #8) > (In reply to comment #7) > > The only property needed for that hash is it should never equals the hash of emptyString(). > > Maybe (hash(emptyString()) ^ 0x100) would work? Filed Bug 115008 to track this issue.