Summary: | Port FontDescriptionKey::computeHash() from legacy IntegerHasher to Hasher | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Chris Dumez <cdumez> | ||||||||
Component: | WebCore Misc. | Assignee: | Chris Dumez <cdumez> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Normal | CC: | ap, benjamin, cmarcelo, darin, ddkilzer, ews-watchlist, ggaren, mmaxfield, rniwa, sam, webkit-bug-importer | ||||||||
Priority: | P2 | Keywords: | InRadar | ||||||||
Version: | WebKit Nightly Build | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Unspecified | ||||||||||
See Also: |
https://bugs.webkit.org/show_bug.cgi?id=176131 https://bugs.webkit.org/show_bug.cgi?id=223858 |
||||||||||
Attachments: |
|
Description
Chris Dumez
2021-03-24 10:44:31 PDT
Created attachment 424155 [details]
Patch
Comment on attachment 424155 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=424155&action=review > Source/WebCore/ChangeLog:13 > + Since we're merely computing a hash here, I think the undefined behavior is acceptable here. Are you saying that even though it's undefined, all compilers we use will always do a sane thing here? Officially, undefined behavior can erase my SSD, which I wouldn't like a hash function to do :) Comment on attachment 424155 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=424155&action=review > Source/WebCore/platform/graphics/FontCache.h:109 > + NO_SANITIZE("undefined") inline unsigned computeHash() const I guess this is OK, because IntegerHasher is deprecated and our stated direction is to move to Hasher instead. If IntegerHasher was not deprecated, I would say that instead we need to do more overloading of the add function in IntegerHasher rather than writing NO_SANITIZE. Maybe we should port this function to use Hasher instead? Comment on attachment 424155 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=424155&action=review >> Source/WebCore/ChangeLog:13 >> + Since we're merely computing a hash here, I think the undefined behavior is acceptable here. > > Are you saying that even though it's undefined, all compilers we use will always do a sane thing here? Officially, undefined behavior can erase my SSD, which I wouldn't like a hash function to do :) That’s right. Converting an int to unsigned without a cast works the same on all compilers, reinterpreting it, even though it’s technically "undefined behavior". This is a problem with UBSan: there are important kinds of problems that are undefined behavior, and there are things that are really no problem at all like this. Comment on attachment 424155 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=424155&action=review >> Source/WebCore/platform/graphics/FontCache.h:109 >> + NO_SANITIZE("undefined") inline unsigned computeHash() const > > I guess this is OK, because IntegerHasher is deprecated and our stated direction is to move to Hasher instead. > > If IntegerHasher was not deprecated, I would say that instead we need to do more overloading of the add function in IntegerHasher rather than writing NO_SANITIZE. > > Maybe we should port this function to use Hasher instead? Or we could just add one explicit cast to unsigned. (In reply to Darin Adler from comment #5) > Comment on attachment 424155 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=424155&action=review > > >> Source/WebCore/platform/graphics/FontCache.h:109 > >> + NO_SANITIZE("undefined") inline unsigned computeHash() const > > > > I guess this is OK, because IntegerHasher is deprecated and our stated direction is to move to Hasher instead. > > > > If IntegerHasher was not deprecated, I would say that instead we need to do more overloading of the add function in IntegerHasher rather than writing NO_SANITIZE. > > > > Maybe we should port this function to use Hasher instead? > > Or we could just add one explicit cast to unsigned. I guess we could port the function to Hasher but all it does is force the caller to static cast to an unsigned integer type before calling Hasher::add(). Will the static_cast<> really silence the UBSan warning? Seems to me that casting a negative int to an unsigned is undefined behavior no matter what. (In reply to Chris Dumez from comment #6) > casting a negative int to an unsigned is undefined behavior > no matter what. There has to be some way to do the conversion that does not rely on undefined behavior. Whether it’s static_cast or a new function we have to write. (In reply to Darin Adler from comment #7) > (In reply to Chris Dumez from comment #6) > > casting a negative int to an unsigned is undefined behavior > > no matter what. > > There has to be some way to do the conversion that does not rely on > undefined behavior. Whether it’s static_cast or a new function we have to > write. Yes, so I initially tried to write such a function. Then I figured it was probably not worth the cost (I think it will involve extra branching) since this is only used for hashing. We don’t want to be required to sprinkle NO_SANITIZE("undefined") calls into our sources every place we hash an int. (In reply to Darin Adler from comment #9) > We don’t want to be required to sprinkle NO_SANITIZE("undefined") calls into > our sources every place we hash an int. Fair point. Let me rethink the approach then. Instead we can have that in a single function inside the Hasher class. It might be harder to do that for IntegerHasher because overloading for int would lead to having to do more overloading now that there is ambiguity. Created attachment 424165 [details]
Patch
I updated the patch to port the code to Hasher as suggested. Set review flag again. Comment on attachment 424165 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=424165&action=review Some nice features of Hasher that this does not take advantage of, that I would like you to be aware of for the future: 1) Can pass an entire collection, like a std::array, and Hasher knows how to hash all the items. Works for any object that has a begin function and that works with a range-based for loop. 2) Can list more than one item in a single call to add, rather than using separate calls to add each thing. 3) Can handle Optional, so no need to write valueOr. 4) Can pass a tuple and it will hash all the items in the tuple. 5) Can hash whole objects, not just integers, so can avoid doing hashes of hashes in most cases. 6) Can write add function overloads for use in combination with the above. > Source/WebCore/platform/graphics/FontCache.h:115 > + add(hasher, m_fontSelectionRequest.weight); > + add(hasher, m_fontSelectionRequest.width); > + add(hasher, m_fontSelectionRequest.slope.valueOr(normalItalicValue())); Could just write this: add(hasher, m_fontSelectionRequest.tied()); > Source/WebCore/platform/graphics/FontCache.h:116 > + add(hasher, m_locale.existingHash()); Could just write this: add(hasher, m_locale); > Source/WebCore/platform/graphics/FontCache.h:117 > for (unsigned flagItem : m_flags) Could just write this: add(hasher, m_flags); Instead of the loop. > Source/WebCore/platform/graphics/FontCache.h:120 > + add(hasher, m_featureSettings.hash()); > + add(hasher, m_variationSettings.hash()); With very little work we could refactor so this doesn’t make a hash out of hashes. Likely just need to make an add(Hasher&, x) overload for FontTaggedSetting. No need to do that now. Created attachment 424209 [details]
Patch
Committed r274992: <https://commits.webkit.org/r274992> All reviewed patches have been landed. Closing bug and clearing flags on attachment 424209 [details]. This patch caused the bug 223858. |