224797 2021-04-19 20:05:21 -0700 [clang] Remove implicit cast related warnings. 2021-04-27 22:25:59 -0700 1 1 1 Unclassified WebKit Platform WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=225139 InRadar P2 Normal --- 1 basuke basuke basuke benjamin cdumez changseok cmarcelo darin esprehn+autocc ews-watchlist glenn kondapallykalyan pdr webkit-bug-importer oldest_to_newest 1752107 0 basuke 2021-04-19 20:05:21 -0700 WTF/Headers\wtf/CheckedArithmetic.h:836:58: warning: implicit conversion from 'std::numeric_limits<unsigned long>::_Ty' (aka 'unsigned long') to 'double' changes value from 18446744073709551615 to 18446744073709551616 [-Wimplicit-const-int-float-conversion] if (!(std::numeric_limits<T>::min() <= result && std::numeric_limits<T>::max() >= result)) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~ ../../Tools/TestWebKitAPI/Tests/WTF/CheckedArithmeticOperations.cpp:511:10: note: in instantiation of member function 'WTF::Checked<uint64_t, WTF::RecordOverflow>::operator/=' requested here size /= 10.5; ^ 1 warning generated. In file included from WebCore/DerivedSources/unified-sources/UnifiedSource-043dd90b-5.cpp:8: ../../Source/WebCore\rendering/RenderBlockFlow.cpp:1785:25: warning: implicit conversion from 'const int' to 'const float' changes value from 33554431 to 33554432 [-Wimplicit-const-int-float-conversion] logicalOffset = intMaxForLayoutUnit; ~ ^~~~~~~~~~~~~~~~~~~ 1 warning generated. 1752110 1 426513 basuke 2021-04-19 20:09:43 -0700 Created attachment 426513 PATCH 1752118 2 basuke 2021-04-19 20:25:44 -0700 Checked::operator /= () is only used in this TestWTF file and using long double wont affect in actual codebase. 1752131 3 426513 darin 2021-04-19 21:46:40 -0700 Comment on attachment 426513 PATCH View in context: https://bugs.webkit.org/attachment.cgi?id=426513&action=review > Source/WTF/wtf/CheckedArithmetic.h:820 > + long double result = rhs * m_value; This looks like a costly solution to this problem, and possibly not portable. Is there a way to do this checking without involving a "long double". > Source/WebCore/ChangeLog:10 > + Added explicit cast for compatibility. > + > + No new tests because there's no practical change. I don’t understand what "compatibility" means here. Compatibility with what? 1752148 4 426513 basuke 2021-04-19 22:39:52 -0700 Comment on attachment 426513 PATCH View in context: https://bugs.webkit.org/attachment.cgi?id=426513&action=review >> Source/WTF/wtf/CheckedArithmetic.h:820 >> + long double result = rhs * m_value; > > This looks like a costly solution to this problem, and possibly not portable. Is there a way to do this checking without involving a "long double". As the warning says: "'unsigned long') to 'double' changes value from 18446744073709551615 to 18446744073709551616", double is not as precise as to hold unsigned long. What if the value is 18446744073709551616, then the value will pass through this check and won't overflow. I cannot judge what range of error can be allowed from this generic implementation, so that it has to be strict. But I didn't think about the portability. Humm, I don't have other solution right now. Let's think about this. >> Source/WebCore/ChangeLog:10 >> + No new tests because there's no practical change. > > I don’t understand what "compatibility" means here. Compatibility with what? I mean it it compatible with the result of implicit cast with explicit cast. That's why technically there's no change in the compilation result. 1752267 5 426513 darin 2021-04-20 08:23:47 -0700 Comment on attachment 426513 PATCH View in context: https://bugs.webkit.org/attachment.cgi?id=426513&action=review >>> Source/WTF/wtf/CheckedArithmetic.h:820 >>> + long double result = rhs * m_value; >> >> This looks like a costly solution to this problem, and possibly not portable. Is there a way to do this checking without involving a "long double". > > As the warning says: "'unsigned long') to 'double' changes value from 18446744073709551615 to 18446744073709551616", double is not as precise as to hold unsigned long. What if the value is 18446744073709551616, then the value will pass through this check and won't overflow. I cannot judge what range of error can be allowed from this generic implementation, so that it has to be strict. But I didn't think about the portability. Humm, I don't have other solution right now. Let's think about this. Comment above says "unsigned long" but this is about 64-bit unsigned integers; "unsigned long" is a 32-bit integer. - We don’t want to use long double when the underlying type is a 32-bit integer. That would hurt efficiency in that case without helping correctness. - We need to add test cases that demonstrate this working incorrectly before we start making changes that aren’t tested. - Do we actually use these function with uint64_t? Instead of making this less efficient and less portable for cases we actually do use, maybe instead we should find a way to make this not compile at all when T is 64-bit for now, while we seek a better result. 1752421 6 basuke 2021-04-20 14:25:40 -0700 (In reply to Darin Adler from comment #5) > Comment on attachment 426513 [details] > PATCH > > View in context: > https://bugs.webkit.org/attachment.cgi?id=426513&action=review > > >>> Source/WTF/wtf/CheckedArithmetic.h:820 > >>> + long double result = rhs * m_value; > >> > >> This looks like a costly solution to this problem, and possibly not portable. Is there a way to do this checking without involving a "long double". > > > > As the warning says: "'unsigned long') to 'double' changes value from 18446744073709551615 to 18446744073709551616", double is not as precise as to hold unsigned long. What if the value is 18446744073709551616, then the value will pass through this check and won't overflow. I cannot judge what range of error can be allowed from this generic implementation, so that it has to be strict. But I didn't think about the portability. Humm, I don't have other solution right now. Let's think about this. > > Comment above says "unsigned long" but this is about 64-bit unsigned > integers; "unsigned long" is a 32-bit integer. Is unsigned long 32-bit on Mac?? It's usually 64-bit on 64-bit architecture. Actually it is Checked<size_t> so it has to be 64-bit. > - We don’t want to use long double when the underlying type is a 32-bit > integer. That would hurt efficiency in that case without helping correctness. Agreed. We need to add such case. > - We need to add test cases that demonstrate this working incorrectly before > we start making changes that aren’t tested. Ditto. > - Do we actually use these function with uint64_t? Instead of making this > less efficient and less portable for cases we actually do use, maybe instead > we should find a way to make this not compile at all when T is 64-bit for > now, while we seek a better result. Okay. I'll create a new bug for that. Removing that from this path. 1752452 7 darin 2021-04-20 15:29:03 -0700 (In reply to Basuke Suzuki from comment #6) > Is unsigned long 32-bit on Mac?? Yes. > It's usually 64-bit on 64-bit architecture. Maybe often, but not "usually". https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models Windows and all Apple platforms use 32-bit longs (LLP64). I understand that on many Unix platforms the compilers are configured for 64-bit longs (LP64). In part because of this we avoid using the type "long" and "unsigned long" almost all the time in WebKit, because the code would just end up being non-portable. Almost any place it’s used, we should be using "int" or "unsigned" instead; this often happens because of confusion since IDL uses "long" and "unsigned long" for the 32-bit types. > Actually it is Checked<size_t> so it has to be 64-bit. OK. On further reflection, it’s possible that long double *is* portable enough in practice for us to use it for this purpose. It’s not guaranteed to be big enough to hold all 64-bit integers, but in practice it probably is on all the platforms we support. This header originally came from another project. Maybe Mozilla? We might want to check how they solved the problem. 1752467 8 basuke 2021-04-20 15:36:25 -0700 Filed. https://bugs.webkit.org/show_bug.cgi?id=224835 1752510 9 426615 basuke 2021-04-20 16:51:15 -0700 Created attachment 426615 PATCH 1752576 10 ews-feeder 2021-04-20 18:43:00 -0700 Committed r276342 (236820@main): <https://commits.webkit.org/236820@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 426615. 1752644 11 basuke 2021-04-20 23:15:53 -0700 (In reply to Darin Adler from comment #7) > (In reply to Basuke Suzuki from comment #6) > > Is unsigned long 32-bit on Mac?? > > Yes. Darin, I wrote a test code and ran on M1 MacBook Air both native and Rosetta. It both says unsigned long is eight byte. https://gist.github.com/basuke/63dff61dcaf2096f88449408aed90781 So it seems Checked with 64-bit type is already used widely on the codebase. 1753354 12 darin 2021-04-22 16:39:08 -0700 Embarrassing that I got that wrong! I was totally incorrect. It’s still true that we mostly avoid the type "unsigned long" in our code because of the portability problems on 64-bit Windows, for example. What files did you find where we were using Checked<unsigned long> (as opposed to Checked<size_t> or Checked<uint64_t>? 1753497 13 webkit-bug-importer 2021-04-23 01:21:11 -0700 <rdar://problem/77061502> 1753835 14 basuke 2021-04-24 00:51:49 -0700 (In reply to Darin Adler from comment #12) > Embarrassing that I got that wrong! I was totally incorrect. > > It’s still true that we mostly avoid the type "unsigned long" in our code > because of the portability problems on 64-bit Windows, for example. > > What files did you find where we were using Checked<unsigned long> (as > opposed to Checked<size_t> or Checked<uint64_t>? Oh, sorry. No, it's not in the code. The compiler deduced the Checked<size_t> to Checked<unsigned long> in the warning message. It's not in the code. Regardless of this, https://bugs.webkit.org/show_bug.cgi?id=224835 is the actual issue we need to solve. 1753863 15 darin 2021-04-24 10:15:02 -0700 Agreed. 426513 2021-04-19 20:09:43 -0700 2021-04-20 16:51:15 -0700 PATCH test.diff text/plain 3488 basuke ZGlmZiAtLWdpdCBhL1NvdXJjZS9XVEYvQ2hhbmdlTG9nIGIvU291cmNlL1dURi9DaGFuZ2VMb2cK aW5kZXggMWU2ZjExYmY3NzZjLi45OTZkMTQxNWI3NWQgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XVEYv Q2hhbmdlTG9nCisrKyBiL1NvdXJjZS9XVEYvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTYgQEAKKzIw MjEtMDQtMTkgIEJhc3VrZSBTdXp1a2kgIDxiYXN1a2Uuc3V6dWtpQHNvbnkuY29tPgorCisgICAg ICAgIFtjbGFuZ10gUmVtb3ZlIGltcGxpY2l0IGNhc3QgcmVsYXRlZCB3YXJuaW5ncy4KKyAgICAg ICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTIyNDc5NworCisgICAg ICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIFRvIGNoZWNrIHRoZSBt aW4vbWF4IHJhbmdlIGZvciB1bnNpZ25lZCBsb25nLCBkb3VibGUgaXMgbm90IGVub3VnaC4KKwor ICAgICAgICAqIHd0Zi9DaGVja2VkQXJpdGhtZXRpYy5oOgorICAgICAgICAoV1RGOjpDaGVja2Vk OjpvcGVyYXRvcio9KToKKyAgICAgICAgKFdURjo6Q2hlY2tlZDo6b3BlcmF0b3IvPSk6CisKIDIw MjEtMDQtMTkgIEtpbW1vIEtpbm51bmVuICA8a2tpbm51bmVuQGFwcGxlLmNvbT4KIAogICAgICAg ICBFbmFibGUgLVd0aHJlYWQtc2FmZXR5LCBhZGQgYXR0cmlidXRlcyB0byBjdXN0b20gbG9jayBj bGFzc2VzLCBhbmQgcHJvdmlkZSBtYWNyb3MgdG8gZGVjbGFyZSBndWFyZHMKZGlmZiAtLWdpdCBh L1NvdXJjZS9XVEYvd3RmL0NoZWNrZWRBcml0aG1ldGljLmggYi9Tb3VyY2UvV1RGL3d0Zi9DaGVj a2VkQXJpdGhtZXRpYy5oCmluZGV4IDc0MGJlNDY2MDhiOC4uMWZjODQyZGJlNGI1IDEwMDY0NAot LS0gYS9Tb3VyY2UvV1RGL3d0Zi9DaGVja2VkQXJpdGhtZXRpYy5oCisrKyBiL1NvdXJjZS9XVEYv d3RmL0NoZWNrZWRBcml0aG1ldGljLmgKQEAgLTgxNyw3ICs4MTcsNyBAQCBwdWJsaWM6CiAKICAg ICBjb25zdCBDaGVja2VkIG9wZXJhdG9yKj0oZG91YmxlIHJocykKICAgICB7Ci0gICAgICAgIGRv dWJsZSByZXN1bHQgPSByaHMgKiBtX3ZhbHVlOworICAgICAgICBsb25nIGRvdWJsZSByZXN1bHQg PSByaHMgKiBtX3ZhbHVlOwogICAgICAgICAvLyBIYW5kbGUgKy8tIGluZmluaXR5IGFuZCBOYU4K ICAgICAgICAgaWYgKCEoc3RkOjpudW1lcmljX2xpbWl0czxUPjo6bWluKCkgPD0gcmVzdWx0ICYm IHN0ZDo6bnVtZXJpY19saW1pdHM8VD46Om1heCgpID49IHJlc3VsdCkpCiAgICAgICAgICAgICB0 aGlzLT5vdmVyZmxvd2VkKCk7CkBAIC04MzEsNyArODMxLDcgQEAgcHVibGljOgogICAgICAgICAg ICAgdGhpcy0+b3ZlcmZsb3dlZCgpOwogICAgICAgICAgICAgcmV0dXJuICp0aGlzOwogICAgICAg ICB9Ci0gICAgICAgIGRvdWJsZSByZXN1bHQgPSBtX3ZhbHVlIC8gcmhzOworICAgICAgICBsb25n IGRvdWJsZSByZXN1bHQgPSBtX3ZhbHVlIC8gcmhzOwogICAgICAgICAvLyBIYW5kbGUgKy8tIGlu ZmluaXR5IGFuZCBOYU4KICAgICAgICAgaWYgKCEoc3RkOjpudW1lcmljX2xpbWl0czxUPjo6bWlu KCkgPD0gcmVzdWx0ICYmIHN0ZDo6bnVtZXJpY19saW1pdHM8VD46Om1heCgpID49IHJlc3VsdCkp CiAgICAgICAgICAgICB0aGlzLT5vdmVyZmxvd2VkKCk7CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2Vi Q29yZS9DaGFuZ2VMb2cgYi9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXggZDY2OWU3YTAy YmRkLi5iNTVkMmQ5NzYwNmQgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwor KysgYi9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKQEAgLTEsMyArMSwxNyBAQAorMjAyMS0wNC0x OSAgQmFzdWtlIFN1enVraSAgPGJhc3VrZS5zdXp1a2lAc29ueS5jb20+CisKKyAgICAgICAgW2Ns YW5nXSBSZW1vdmUgaW1wbGljaXQgY2FzdCByZWxhdGVkIHdhcm5pbmdzLgorICAgICAgICBodHRw czovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MjI0Nzk3CisKKyAgICAgICAgUmV2 aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgQWRkZWQgZXhwbGljaXQgY2FzdCBm b3IgY29tcGF0aWJpbGl0eS4KKworICAgICAgICBObyBuZXcgdGVzdHMgYmVjYXVzZSB0aGVyZSdz IG5vIHByYWN0aWNhbCBjaGFuZ2UuCisKKyAgICAgICAgKiByZW5kZXJpbmcvUmVuZGVyQmxvY2tG bG93LmNwcDoKKyAgICAgICAgKFdlYkNvcmU6OlJlbmRlckJsb2NrRmxvdzo6YWRqdXN0TGluZVBv c2l0aW9uRm9yUGFnaW5hdGlvbik6CisKIDIwMjEtMDQtMTkgIFdlbnNvbiBIc2llaCAgPHdlbnNv bl9oc2llaEBhcHBsZS5jb20+CiAKICAgICAgICAgUmVuYW1lIEZsb2F0UXVhZDo6aXNFbXB0eSgp IHRvIGJvdW5kaW5nQm94SXNFbXB0eSgpIGFuZCByZWltcGxlbWVudCBpc0VtcHR5KCkKZGlmZiAt LWdpdCBhL1NvdXJjZS9XZWJDb3JlL3JlbmRlcmluZy9SZW5kZXJCbG9ja0Zsb3cuY3BwIGIvU291 cmNlL1dlYkNvcmUvcmVuZGVyaW5nL1JlbmRlckJsb2NrRmxvdy5jcHAKaW5kZXggMDNlNDQ3MDhj ODI4Li43NjVlMzFlYzQzYzAgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJDb3JlL3JlbmRlcmluZy9S ZW5kZXJCbG9ja0Zsb3cuY3BwCisrKyBiL1NvdXJjZS9XZWJDb3JlL3JlbmRlcmluZy9SZW5kZXJC bG9ja0Zsb3cuY3BwCkBAIC0xNzgyLDggKzE3ODIsOCBAQCB2b2lkIFJlbmRlckJsb2NrRmxvdzo6 YWRqdXN0TGluZVBvc2l0aW9uRm9yUGFnaW5hdGlvbihSb290SW5saW5lQm94KiBsaW5lQm94LCBM YQogICAgICAgICAvLyB0b3Agb2YgdGhlIHBhZ2UuCiAgICAgICAgIC8vIEZJWE1FOiBXZSBhcmUg c3RpbGwgaG9ub3JpbmcgZ2lnYW50aWMgbWFyZ2lucywgd2hpY2ggZG9lcyBsZWF2ZSBvcGVuIHRo ZSBwb3NzaWJpbGl0eSBvZiBibGFuayBwYWdlcyBjYXVzZWQgYnkgdGhpcyBoZXVyaXN0aWMuIEl0 IHJlbWFpbnMgdG8gYmUgc2VlbiB3aGV0aGVyIG9yIG5vdAogICAgICAgICAvLyB0aGlzIHdpbGwg YmUgYSByZWFsLXdvcmxkIGlzc3VlLiBGb3Igbm93IHdlIGRvbid0IHRyeSB0byBkZWFsIHdpdGgg dGhpcyBwcm9ibGVtLgotICAgICAgICBsb2dpY2FsT2Zmc2V0ID0gaW50TWF4Rm9yTGF5b3V0VW5p dDsKLSAgICAgICAgbG9naWNhbEJvdHRvbSA9IGludE1pbkZvckxheW91dFVuaXQ7CisgICAgICAg IGxvZ2ljYWxPZmZzZXQgPSBzdGF0aWNfY2FzdDxmbG9hdD4oaW50TWF4Rm9yTGF5b3V0VW5pdCk7 CisgICAgICAgIGxvZ2ljYWxCb3R0b20gPSBzdGF0aWNfY2FzdDxmbG9hdD4oaW50TWluRm9yTGF5 b3V0VW5pdCk7CiAgICAgICAgIGxpbmVCb3gtPmNvbXB1dGVSZXBsYWNlZEFuZFRleHRMaW5lVG9w QW5kQm90dG9tKGxvZ2ljYWxPZmZzZXQsIGxvZ2ljYWxCb3R0b20pOwogICAgICAgICBsaW5lSGVp Z2h0ID0gbG9naWNhbEJvdHRvbSAtIGxvZ2ljYWxPZmZzZXQ7CiAgICAgICAgIGlmIChsb2dpY2Fs T2Zmc2V0ID09IGludE1heEZvckxheW91dFVuaXQgfHwgbGluZUhlaWdodCA+IHBhZ2VMb2dpY2Fs SGVpZ2h0KSB7DQo= 426615 2021-04-20 16:51:15 -0700 2021-04-20 18:43:01 -0700 PATCH test.diff text/plain 1878 basuke ZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZyBiL1NvdXJjZS9XZWJDb3JlL0No YW5nZUxvZwppbmRleCAxMzc4ZTI3ZTM3YjguLjBjOTcyYTEzOTBhZCAxMDA2NDQKLS0tIGEvU291 cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAt MSwzICsxLDE4IEBACisyMDIxLTA0LTIwICBCYXN1a2UgU3V6dWtpICA8YmFzdWtlLnN1enVraUBz b255LmNvbT4KKworICAgICAgICBbY2xhbmddIFJlbW92ZSBpbXBsaWNpdCBjYXN0IHJlbGF0ZWQg d2FybmluZ3MuCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9p ZD0yMjQ3OTcKKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAg ICBBZGRlZCBleHBsaWNpdCBjYXN0IHRvIHN1cHByZXNzIHdhcm5pbmcuCisgICAgICAgIEJlaGF2 aW9yIGlzIG5vdCBjaGFuZ2VkIGZyb20gaW1wbGljaXQgY2FzdC4KKworICAgICAgICBObyBuZXcg dGVzdHMgYmVjYXVzZSB0aGVyZSdzIG5vIGJlaGF2aW9yIGNoYW5nZS4KKworICAgICAgICAqIHJl bmRlcmluZy9SZW5kZXJCbG9ja0Zsb3cuY3BwOgorICAgICAgICAoV2ViQ29yZTo6UmVuZGVyQmxv Y2tGbG93OjphZGp1c3RMaW5lUG9zaXRpb25Gb3JQYWdpbmF0aW9uKToKKwogMjAyMS0wNC0yMCAg QWRpdHlhIEtlZXJ0aGkgIDxha2VlcnRoaUBhcHBsZS5jb20+CiAKICAgICAgICAgW2lPU11bRkNS XSBVcGRhdGUgZGF0ZS90aW1lIHBpY2tlciBhcHBlYXJhbmNlCmRpZmYgLS1naXQgYS9Tb3VyY2Uv V2ViQ29yZS9yZW5kZXJpbmcvUmVuZGVyQmxvY2tGbG93LmNwcCBiL1NvdXJjZS9XZWJDb3JlL3Jl bmRlcmluZy9SZW5kZXJCbG9ja0Zsb3cuY3BwCmluZGV4IDAzZTQ0NzA4YzgyOC4uNzY1ZTMxZWM0 M2MwIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViQ29yZS9yZW5kZXJpbmcvUmVuZGVyQmxvY2tGbG93 LmNwcAorKysgYi9Tb3VyY2UvV2ViQ29yZS9yZW5kZXJpbmcvUmVuZGVyQmxvY2tGbG93LmNwcApA QCAtMTc4Miw4ICsxNzgyLDggQEAgdm9pZCBSZW5kZXJCbG9ja0Zsb3c6OmFkanVzdExpbmVQb3Np dGlvbkZvclBhZ2luYXRpb24oUm9vdElubGluZUJveCogbGluZUJveCwgTGEKICAgICAgICAgLy8g dG9wIG9mIHRoZSBwYWdlLgogICAgICAgICAvLyBGSVhNRTogV2UgYXJlIHN0aWxsIGhvbm9yaW5n IGdpZ2FudGljIG1hcmdpbnMsIHdoaWNoIGRvZXMgbGVhdmUgb3BlbiB0aGUgcG9zc2liaWxpdHkg b2YgYmxhbmsgcGFnZXMgY2F1c2VkIGJ5IHRoaXMgaGV1cmlzdGljLiBJdCByZW1haW5zIHRvIGJl IHNlZW4gd2hldGhlciBvciBub3QKICAgICAgICAgLy8gdGhpcyB3aWxsIGJlIGEgcmVhbC13b3Js ZCBpc3N1ZS4gRm9yIG5vdyB3ZSBkb24ndCB0cnkgdG8gZGVhbCB3aXRoIHRoaXMgcHJvYmxlbS4K LSAgICAgICAgbG9naWNhbE9mZnNldCA9IGludE1heEZvckxheW91dFVuaXQ7Ci0gICAgICAgIGxv Z2ljYWxCb3R0b20gPSBpbnRNaW5Gb3JMYXlvdXRVbml0OworICAgICAgICBsb2dpY2FsT2Zmc2V0 ID0gc3RhdGljX2Nhc3Q8ZmxvYXQ+KGludE1heEZvckxheW91dFVuaXQpOworICAgICAgICBsb2dp Y2FsQm90dG9tID0gc3RhdGljX2Nhc3Q8ZmxvYXQ+KGludE1pbkZvckxheW91dFVuaXQpOwogICAg ICAgICBsaW5lQm94LT5jb21wdXRlUmVwbGFjZWRBbmRUZXh0TGluZVRvcEFuZEJvdHRvbShsb2dp Y2FsT2Zmc2V0LCBsb2dpY2FsQm90dG9tKTsKICAgICAgICAgbGluZUhlaWdodCA9IGxvZ2ljYWxC b3R0b20gLSBsb2dpY2FsT2Zmc2V0OwogICAgICAgICBpZiAobG9naWNhbE9mZnNldCA9PSBpbnRN YXhGb3JMYXlvdXRVbml0IHx8IGxpbmVIZWlnaHQgPiBwYWdlTG9naWNhbEhlaWdodCkgew0K