Bug 114970

Summary: StringImpl.h should compile with -Wshorten-64-to-32
Product: WebKit Reporter: David Kilzer (:ddkilzer) <ddkilzer>
Component: Web Template FrameworkAssignee: David Kilzer (:ddkilzer) <ddkilzer>
Status: RESOLVED FIXED    
Severity: Normal CC: benjamin, cmarcelo, commit-queue, darin
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 107093    
Attachments:
Description Flags
Patch v1 none

Description David Kilzer (:ddkilzer) 2013-04-22 11:25:27 PDT
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);
                     ~~~~   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Comment 1 David Kilzer (:ddkilzer) 2013-04-22 11:27:24 PDT
Created attachment 199053 [details]
Patch v1
Comment 2 Darin Adler 2013-04-22 11:33:28 PDT
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.
Comment 3 WebKit Commit Bot 2013-04-22 12:11:27 PDT
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 4 WebKit Commit Bot 2013-04-22 12:12:20 PDT
Comment on attachment 199053 [details]
Patch v1

Clearing flags on attachment: 199053

Committed r148900: <http://trac.webkit.org/changeset/148900>
Comment 5 WebKit Commit Bot 2013-04-22 12:12:22 PDT
All reviewed patches have been landed.  Closing bug.
Comment 6 David Kilzer (:ddkilzer) 2013-04-22 12:20:04 PDT
(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?
Comment 7 Benjamin Poulain 2013-04-22 15:48:53 PDT
(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 :)
Comment 8 Darin Adler 2013-04-22 16:34:51 PDT
(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?
Comment 9 David Kilzer (:ddkilzer) 2013-04-22 19:41:59 PDT
(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.