95718 2012-09-04 01:08:39 -0700 [WK2][GTK] Add missing SPELLCHECK macro to TextCheckerGtk.cpp 2017-03-11 10:49:09 -0800 1 1 1 Unclassified WebKit WebKit2 528+ (Nightly build) Unspecified Unspecified NEW P2 Normal --- 1 g.czajkowski g.czajkowski bugs-noreply cgarcia mario mrobinson ravi.kasibhatla oldest_to_newest 710871 0 g.czajkowski 2012-09-04 01:08:39 -0700 WebKit-Gtk uses SPELLCHECK macro for files that implements spellchecking feature. It is missing for TextCheckerGtk.cpp 710873 1 161983 g.czajkowski 2012-09-04 01:10:31 -0700 Created attachment 161983 proposed patch 710942 2 mario 2012-09-04 03:52:29 -0700 Hrm... I think this is not actually a bug and thus there's no need to add these macros in UIProcess/gtk/TextCheckerGtk.cpp since that file is at a very low level in the UIProcess, that should be (and it is, I think) independent of this kind of configuration options. After all, the implementation of TextChecker's methods will rely on the API client (WKTextCheckerClient, in this case) provided for the specific platform, which should only be set if the SPELLCHECK feature is enabled, being this the correct place IMHO to use the macro. For the sake of clarity, this is how we do it in WebKit2GTK: 1. In WebKitWebContext.cpp, we create an instance of our internal class (not exposed through the WK2GTK API) WebKitTextChecker: static gpointer createDefaultWebContext(gpointer) { [...] #if ENABLE(SPELLCHECK) webContext->priv->textChecker = WebKitTextChecker::create(); #endif return webContext.get(); } 2. In the implementation of WebKitTextChecker::create(), we provide an implementation for the WKTextCheckerClient API client: WebKitTextChecker::WebKitTextChecker() : m_textChecker(WebCore::TextCheckerEnchant::create()) , m_spellCheckingEnabled(false) { WKTextCheckerClient wkTextCheckerClient = { kWKTextCheckerClientCurrentVersion, this, // clientInfo 0, // continuousSpellCheckingAllowed continuousSpellCheckingEnabledCallback, setContinuousSpellCheckingEnabledCallback, [...] }; [...] } 3. Finally, also in WebKitTextChecker::create(), we set that one as the API client to be used from UIProcess/WebTextChecker.cpp, and also from UIProcess/gtk/TextCheckerGtk.cpp: WebKitTextChecker::WebKitTextChecker() : m_textChecker(WebCore::TextCheckerEnchant::create()) , m_spellCheckingEnabled(false) { [...] WKTextCheckerSetClient(&wkTextCheckerClient); } So, if ENABLE(SPELLCHECK) macro returned false, we wouldn't have done any of this in the first place and so, all the calls in UIProcess/gtk/TextCheckerGtk.cpp would just do nothing, as they would finally execute methods of UIProcess/WebTextCheckerClient.cpp, like this one: void WebTextCheckerClient::checkSpellingOfString(uint64_t tag, const String& text, int32_t& misspellingLocation, int32_t& misspellingLength) { if (!m_client.checkSpellingOfString) return; m_client.checkSpellingOfString(tag, toAPI(text.impl()), &misspellingLocation, &misspellingLength, m_client.clientInfo); } Does all this rant make sense? Am I missing anything? 711053 3 g.czajkowski 2012-09-04 06:28:58 -0700 (In reply to comment #2) > Hrm... I think this is not actually a bug and thus there's no need to add these macros in UIProcess/gtk/TextCheckerGtk.cpp since that file is at a very low level in the UIProcess, that should be (and it is, I think) independent of this kind of configuration options. > > After all, the implementation of TextChecker's methods will rely on the API client (WKTextCheckerClient, in this case) provided for the specific platform, which should only be set if the SPELLCHECK feature is enabled, being this the correct place IMHO to use the macro. First of all thanks for very good review and nice explanations of WebKit2GTK design of spellchecking feature! I've found this issue while implementing TextCheckerEfl.cpp for WebKit2EFL (under review here https://bugs.webkit.org/show_bug.cgi?id=91854) which I can say, looks very similar to TextCheckerGtk and TextCheckerMac:) > > For the sake of clarity, this is how we do it in WebKit2GTK: > > 1. In WebKitWebContext.cpp, we create an instance of our internal class (not > exposed through the WK2GTK API) WebKitTextChecker: > > static gpointer createDefaultWebContext(gpointer) > { > [...] > #if ENABLE(SPELLCHECK) > webContext->priv->textChecker = WebKitTextChecker::create(); > #endif > return webContext.get(); > } > > 2. In the implementation of WebKitTextChecker::create(), we provide an implementation for the WKTextCheckerClient API client: > > WebKitTextChecker::WebKitTextChecker() > : m_textChecker(WebCore::TextCheckerEnchant::create()) > , m_spellCheckingEnabled(false) > { > WKTextCheckerClient wkTextCheckerClient = { > kWKTextCheckerClientCurrentVersion, > this, // clientInfo > 0, // continuousSpellCheckingAllowed > continuousSpellCheckingEnabledCallback, > setContinuousSpellCheckingEnabledCallback, > [...] > }; > [...] > } > > 3. Finally, also in WebKitTextChecker::create(), we set that one as the > API client to be used from UIProcess/WebTextChecker.cpp, and also from > UIProcess/gtk/TextCheckerGtk.cpp: > > WebKitTextChecker::WebKitTextChecker() > : m_textChecker(WebCore::TextCheckerEnchant::create()) > , m_spellCheckingEnabled(false) > { > [...] > WKTextCheckerSetClient(&wkTextCheckerClient); > } > > So, if ENABLE(SPELLCHECK) macro returned false, we wouldn't have done any of this in the first place and so, all the calls in UIProcess/gtk/TextCheckerGtk.cpp would just do nothing, as they would finally execute methods of UIProcess/WebTextCheckerClient.cpp, like this one: > > > void WebTextCheckerClient::checkSpellingOfString(uint64_t tag, const String& text, int32_t& misspellingLocation, int32_t& misspellingLength) > { > if (!m_client.checkSpellingOfString) > return; > > m_client.checkSpellingOfString(tag, toAPI(text.impl()), &misspellingLocation, &misspellingLength, m_client.clientInfo); > } > > Does all this rant make sense? Am I missing anything? I agree with you that TextChecker's methods just call client's methods defined by WKTextChecker's callbacks. If they are not set, it's safe to call them even SPELLCHECK macro is disabled (as you pointed out WebTextCheckerClient first checkc whether the client exists). But wouldn't be better to add the SPELLCHECK macro for below reasons: - to just do not compile that part of the code, especially if we have possibility to implemented port specific feature and already have macro? - to increase source readability, if someone looks at the code it's not clear that the part of code works OK only if SPELLCHECK is ON, - to consistency with files that implement spellchecking (it looks like TextCheckerGtk makes an exception) If you don't like this change just feel free and close this bug :) 711088 4 mario 2012-09-04 07:03:17 -0700 (In reply to comment #3) > [...] > First of all thanks for very good review and nice explanations of > WebKit2GTK design of spellchecking feature! You're welcome. Glad to see you find it useful. > [...] > I agree with you that TextChecker's methods just call client's methods > defined by WKTextChecker's callbacks. If they are not set, it's safe to > call them even SPELLCHECK macro is disabled (as you pointed out > WebTextCheckerClient first checkc whether the client exists). Yes, and I think that's precisely one of the nice features of this kind of implementations (not only talking about the TextChecker, but more in general): to allow having the possibility of writing new platform-specific components in for specific features and "plugging" them into the generic implementation parts already provided in UIProcess. > But wouldn't be better to add the SPELLCHECK macro for below reasons: > - to just do not compile that part of the code, especially if we have > possibility to implemented port specific feature and already have macro? I think you could achieve a similar effect by adding the right conditions in the makefile, so you just compile the files you need depending on the SPELLCHECK feature being enabled or not. Actually, I think I did that in a preliminary version of my patch for GTK, but then I decided not to do it at some point, because I thought it was clearer. > - to increase source readability, if someone looks at the code it's not > clear that the part of code works OK only if SPELLCHECK is ON, I can't deny this. Of course having the SPELLCHECK macro used in TextCheckerGtk.cpp will make it clearer for readers looking at that file. In the other hand, I also think that a reader really into knowing how spell checking works in a platform will at some point (probably even sooner) end up looking at UIProcess/API/<platform> and there (s)he will find the SPELLCHECK macro anyway. Not an strong opinion though. Just trying to share my thoughts > - to consistency with files that implement spellchecking (it looks > like TextCheckerGtk makes an exception) Hrm.. I'm not sure. If I grep for SPELLCHECK in WebKit2/ folder: ChangeLog:4569: * GNUmakefile.am: Add flags to handle the SPELLCHECK feature. ChangeLog:5606: * GNUmakefile.am: Add flags to handle the SPELLCHECK feature. GNUmakefile.am:188:if ENABLE_SPELLCHECK GNUmakefile.am:190: -DENABLE_SPELLCHECK=1 \ UIProcess/API/gtk/WebKitTextChecker.h:23:#if ENABLE(SPELLCHECK) UIProcess/API/gtk/WebKitTextChecker.h:59:#endif // ENABLE(SPELLCHECK) UIProcess/API/gtk/WebKitTextChecker.cpp:29:#if ENABLE(SPELLCHECK) UIProcess/API/gtk/WebKitTextChecker.cpp:162:#endif // ENABLE(SPELLCHECK) UIProcess/API/gtk/WebKitWebContext.cpp:104:#if ENABLE(SPELLCHECK) UIProcess/API/gtk/WebKitWebContext.cpp:162:#if ENABLE(SPELLCHECK) UIProcess/API/gtk/WebKitWebContext.cpp:470:#if ENABLE(SPELLCHECK) UIProcess/API/gtk/WebKitWebContext.cpp:488:#if ENABLE(SPELLCHECK) UIProcess/API/gtk/WebKitWebContext.cpp:510:#if ENABLE(SPELLCHECK) UIProcess/API/gtk/WebKitWebContext.cpp:539:#if ENABLE(SPELLCHECK) ... I don't see any usage of that macro out of UIProcess/API/gtk, which is right IMHO because it happens at the platform API level. However this change your proposing happens at the level of WebKit2 UIProcess's implementation level (UIProcess), which should be as much agnostic of this kind of things as possible, I think. > If you don't like this change just feel free and close this bug :) Oh, no! I won't do it :-) I'm just sharing my thoughts on this in order to help, not that I'm 100% sure I'm completely right or something. Actually, I could very well be perfectly wrong :-) I would appreciate if someone else with experience in WebKit2GTK could drop some comments on this topic too. Martin? Carlos? ;-) 711116 5 g.czajkowski 2012-09-04 07:50:03 -0700 (In reply to comment #4) > (In reply to comment #3) > > But wouldn't be better to add the SPELLCHECK macro for below reasons: > > - to just do not compile that part of the code, especially if we have > > possibility to implemented port specific feature and already have macro? > > I think you could achieve a similar effect by adding the right conditions in the makefile, so you just compile the files you need depending on the SPELLCHECK feature being enabled or not. > > Actually, I think I did that in a preliminary version of my patch for GTK, but then I decided not to do it at some point, because I thought it was clearer. As I understand TextChecker class takes responsibility of public interface for WebKit2 and its implementation is placed in port's specific files for example, {port}/TextChecker{Port}.cpp. In my opinion adding the right conditions (as I assume disabling TextCheckerGtk.cpp if SPELLCHECK is OGG) to the makefile probably won't work - undefined reference may occur while linking process . Please correct me if I am wrong. > > > - to increase source readability, if someone looks at the code it's not > > clear that the part of code works OK only if SPELLCHECK is ON, > > I can't deny this. Of course having the SPELLCHECK macro used in TextCheckerGtk.cpp will make it clearer for readers looking at that file. > > In the other hand, I also think that a reader really into knowing how spell checking works in a platform will at some point (probably even sooner) end up looking at UIProcess/API/<platform> and there (s)he will find the SPELLCHECK macro anyway. > > Not an strong opinion though. Just trying to share my thoughts There are a lot of files/classes in WebKi2 for spelling for example, TextChecker, WebTextChecker, WebKitTextChecker, WKTextChecker. I think it's a little annoying to browse them to finally find SPELLCHECK macro. > > > - to consistency with files that implement spellchecking (it looks > > like TextCheckerGtk makes an exception) > > Hrm.. I'm not sure. If I grep for SPELLCHECK in WebKit2/ folder: > > ChangeLog:4569: * GNUmakefile.am: Add flags to handle the SPELLCHECK feature. > ChangeLog:5606: * GNUmakefile.am: Add flags to handle the SPELLCHECK feature. > GNUmakefile.am:188:if ENABLE_SPELLCHECK > GNUmakefile.am:190: -DENABLE_SPELLCHECK=1 \ > UIProcess/API/gtk/WebKitTextChecker.h:23:#if ENABLE(SPELLCHECK) > UIProcess/API/gtk/WebKitTextChecker.h:59:#endif // ENABLE(SPELLCHECK) > UIProcess/API/gtk/WebKitTextChecker.cpp:29:#if ENABLE(SPELLCHECK) > UIProcess/API/gtk/WebKitTextChecker.cpp:162:#endif // ENABLE(SPELLCHECK) > UIProcess/API/gtk/WebKitWebContext.cpp:104:#if ENABLE(SPELLCHECK) > UIProcess/API/gtk/WebKitWebContext.cpp:162:#if ENABLE(SPELLCHECK) > UIProcess/API/gtk/WebKitWebContext.cpp:470:#if ENABLE(SPELLCHECK) > UIProcess/API/gtk/WebKitWebContext.cpp:488:#if ENABLE(SPELLCHECK) > UIProcess/API/gtk/WebKitWebContext.cpp:510:#if ENABLE(SPELLCHECK) > UIProcess/API/gtk/WebKitWebContext.cpp:539:#if ENABLE(SPELLCHECK) > > > ... I don't see any usage of that macro out of UIProcess/API/gtk, which is right IMHO because it happens at the platform API level. GNUmakefile.am disables at the compile time TextCheckerEnchant,cpp and WebKitTextChecker.cpp files that are placed outside UIProcess/API/gtk and as I mentioned above in my opinion we can not just that in case of TextCheckerGtk.cpp Anyway I can find SPELLCHECK macro in TextCheckerEnchant{h.cpp} and WebKitTextChecker{h.cpp} but my sources may be out of date. > > However this change your proposing happens at the level of WebKit2 UIProcess's implementation level (UIProcess), which should be as much agnostic of this kind of things as possible, I think. > > > If you don't like this change just feel free and close this bug :) > > Oh, no! I won't do it :-) > > I'm just sharing my thoughts on this in order to help, not that I'm 100% sure I'm completely right or something. Actually, I could very well be perfectly wrong :-) > > I would appreciate if someone else with experience in WebKit2GTK could drop some comments on this topic too. Martin? Carlos? ;-) Ok. Anyway thanks for sharing your knowledge about spellchecking it's really precious for me as we are contributing spellchecking for WebKit2EFL. 711944 6 mario 2012-09-05 04:40:07 -0700 (In reply to comment #5) >[...] > As I understand TextChecker class takes responsibility of public interface > for WebKit2 and its implementation is placed in port's specific files for > example, {port}/TextChecker{Port}.cpp. Well, actually TextChecker and WebTextChecker classes are at one level (the lowest level in WK2's UI process), then we have WKTextChecker at a higher level (the cross-platform C API) and finally we have WebKitTextChecker in the highest level (the platform-specific API). It's something like this, from lower to higher levels in WK2's UI Process: TextChecker / WebTextChecker <---> WKTextChecker <---> WebKitTextChecker ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^ Implementation layer C API layer <platform> API layer It's messy, I know (at least it was messy for me first time I got into it), but the point is that IMHO the ENABLE(SPELLCHECK) guards should happen only at the level of the <platform> API layer, which were you most likely will start working from when adding a new implementation for a different platform. > In my opinion adding the right conditions (as I assume disabling > TextCheckerGtk.cpp if SPELLCHECK is OGG) to the makefile probably won't > work - undefined reference may occur while linking process . > Please correct me if I am wrong. Yes, it won't simply work by just using some ifs in the makefiles, you probably would need to make more changes (even in the source code). My point was that I would go that path only if I was really concerned about not compiling those generic hooks in the "implementation layer". But I personally think it doesn't pays off and so that's why I finally didn't mess with that either for GTK. > [...] > There are a lot of files/classes in WebKi2 for spelling for example, > TextChecker, WebTextChecker, WebKitTextChecker, WKTextChecker. > I think it's a little annoying to browse them to finally find > SPELLCHECK macro. I agree there are a lot of similar related files in WK2 for this, and I also think that's a little bit annoying because it's a bit confusing, at least the first time you face them (at least it was for me). But, in the other hand, if you think of them with the "diagram" I wrote above in mind, it's very clear that each of them respond to a very specific purpose in their very specific levels of abstraction, and also that the entry point for a platform is always the <platform> API layer (thus, "WebKitTextChecker"), which is where I would expect to find the macro in the first place. > > > - to consistency with files that implement spellchecking (it looks > > > like TextCheckerGtk makes an exception) > > > > Hrm.. I'm not sure. If I grep for SPELLCHECK in WebKit2/ folder: > > [...] > > ... I don't see any usage of that macro out of UIProcess/API/gtk, > > which is right IMHO because it happens at the platform API level. > > GNUmakefile.am disables at the compile time TextCheckerEnchant,cpp and > WebKitTextChecker.cpp files that are placed outside UIProcess/API/gtk > and as I mentioned above in my opinion we can not just that in case of > TextCheckerGtk.cpp For TextCheckerEnchant it makes sense not to even compile it when SPELLCHECK is not enabled, since for that to happen you need to have libenchant's development package installed on your system. So, if you don't have it there's nothing to do there. But TextCheckerGtk.cpp is not at a so low level as TextCheckerEnchant.cpp, since the former is in WebKit2/UIProcess, which means as much generic and cross-platform code as possible, and the later is in WebCore/platform, which is obviously platform-dependant code in the lowest (almost!) level of the WebKit project: WebCore. So, I think both files are not comparable in this regard. > Anyway I can find SPELLCHECK macro in TextCheckerEnchant{h.cpp} and > WebKitTextChecker{h.cpp} but my sources may be out of date. ...which, as I said, it's perfectly fine, since both files are located at platform-specific levels: TextCheckerEnchant{h.cpp}: WebCore/platform WebKitTextChecker{h.cpp}: WebKit2/UIProcess/API/gtk > > I would appreciate if someone else with experience in WebKit2GTK could drop some comments on this topic too. Martin? Carlos? ;-) > > Ok. Anyway thanks for sharing your knowledge about spellchecking it's > really precious for me as we are contributing spellchecking for WebKit2EFL. Glad to be helpful. Let's see what others think, though. As I said, I must be wrong after all :-) 711953 7 mario 2012-09-05 04:50:59 -0700 I just realized my previous comment needs one clarification at least... (In reply to comment #6) > [...] > But TextCheckerGtk.cpp is not at a so low level as TextCheckerEnchant.cpp, > since the former is in WebKit2/UIProcess, which means as much generic and > cross-platform code as possible, and the later is in WebCore/platform, > which is obviously platform-dependant code in the lowest (almost!) level > of the WebKit project: WebCore. > > So, I think both files are not comparable in this regard. I know that WebKit2/UIProcess/gtk/TextCheckerGtk.cpp is a GTK specific file, so that probably makes my comment a bit confusing since I'm later saying this: > > Anyway I can find SPELLCHECK macro in TextCheckerEnchant{h.cpp} and > > WebKitTextChecker{h.cpp} but my sources may be out of date. > >...which, as I said, it's perfectly fine, since both files are located > at platform-specific levels: > > TextCheckerEnchant{h.cpp}: WebCore/platform > WebKitTextChecker{h.cpp}: WebKit2/UIProcess/API/gtk When I say that I find the ENABLE(SPELLCHECK) in those cases because they are "located at platform-specific levels", the important concept here from my point of view is "level". - WebKitTextChecker{h.cpp} is in WebKit2/UIProcess/API/gtk, which is the closest level to applications using WebKit2GTK. - TextCheckerEnchant{h.cpp} is in WebCore/platform/enchant, which is the closest level to the spell-checking technologie behind used (enchant). However, even if WebKit2/UIProcess/gtk/TextCheckerGtk.cpp is obviously a GTK specific file, it is not at the same kind of level than those other two files, since it's at WebKit2's UIProcess lowest level: what they call the cross-platform (well... almost!) implementation layer". Hope now it's clearer 713013 8 g.czajkowski 2012-09-06 01:20:11 -0700 Thanks again for kind explanation and a big portion very useful information for us. As a conclusion we can say that it's no good way using SPELLCHECK macro in TextChecker because it's some kind of violation of "implementation layer" mainly placed in TextChecker and WebTextChecker. This is fine for me especially if TextChecker's implementation in TextCheckerGtk is very generic and universal that there is no any issues when SPELLCHECK macro is OFF. If you decide that this macro is not necessary in TextCheckerGtk.cpp please close this bug, then I am going to remove that one from TextCheckerEfl.cpp (https://bugs.webkit.org/show_bug.cgi?id=91854) 713129 9 mario 2012-09-06 03:27:18 -0700 (In reply to comment #8) > Thanks again for kind explanation and a big portion very useful > information for us. Glad to help. > As a conclusion we can say that it's no good way using SPELLCHECK macro in > TextChecker because it's some kind of violation of "implementation layer" > mainly placed in TextChecker and WebTextChecker. This is fine for me especially > if TextChecker's implementation in TextCheckerGtk is very generic and universal > that there is no any issues when SPELLCHECK macro is OFF. That would be my conclusion too, yes. > If you decide that this macro is not necessary in TextCheckerGtk.cpp please > close this bug, then I am going to remove that one from TextCheckerEfl.cpp > (https://bugs.webkit.org/show_bug.cgi?id=91854) Sounds good to me, but I first would prefer someone else to double check this, just to be at least 99% sure :-) 976966 10 161983 andersca 2014-02-05 11:14:16 -0800 Comment on attachment 161983 proposed patch Clearing review flag on patches from before 2014. If this patch is still relevant, please reset the r? flag. 161983 2012-09-04 01:10:31 -0700 2014-02-05 11:14:14 -0800 proposed patch add_spellcheck_macro.patch text/plain 7134 g.czajkowski ZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQyL0NoYW5nZUxvZyBiL1NvdXJjZS9XZWJLaXQyL0No YW5nZUxvZwppbmRleCBlYWFlN2Y4Li43OGUxNjA4IDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViS2l0 Mi9DaGFuZ2VMb2cKKysrIGIvU291cmNlL1dlYktpdDIvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMzQg QEAKKzIwMTItMDktMDMgIEdyemVnb3J6IEN6YWprb3dza2kgIDxnLmN6YWprb3dza2lAc2Ftc3Vu Zy5jb20+CisKKyAgICAgICAgW1dLMl1bR1RLXSBBZGQgbWlzc2luZyBTUEVMTENIRUNLIG1hY3Jv IHRvIFRleHRDaGVja2VyR3RrLmNwcAorICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9z aG93X2J1Zy5jZ2k/aWQ9OTU3MTgKKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMh KS4KKworICAgICAgICBBZGRzIFNQRUxMQ0hFQ0sgbWFjcm8gdG8gdGhlIGJvZHkgb2YgVGV4dENo ZWNrZXIncyBtZXRob2RzLgorICAgICAgICBUaGUgVGV4dENoZWNrZXIgY2xhc3MgaXMgYW4gcHVi bGljIGludGVyZmFjZSBtYWlubHkgdXNlZCBpbiBVSVByb2Nlc3MuCisgICAgICAgIEVhY2ggcG9y dCBpbXBsZW1lbnRzIHRoZSBUZXh0Q2hlY2tlciBpbnRlcmZhY2UgYWNjb3JkaW5nIHRvIGl0cyBu ZWVkcy4KKworICAgICAgICAqIFVJUHJvY2Vzcy9ndGsvVGV4dENoZWNrZXJHdGsuY3BwOgorICAg ICAgICBBbGwgbWV0aG9kcyBhcmUgZ3VhcmQgd2l0aCBTUEVMTENIRUNLIG1hY3JvLgorICAgICAg ICAoV2ViS2l0OjpUZXh0Q2hlY2tlcjo6c3RhdGUpOgorICAgICAgICAoV2ViS2l0OjpUZXh0Q2hl Y2tlcjo6aXNDb250aW51b3VzU3BlbGxDaGVja2luZ0FsbG93ZWQpOgorICAgICAgICAoV2ViS2l0 OjpUZXh0Q2hlY2tlcjo6c2V0Q29udGludW91c1NwZWxsQ2hlY2tpbmdFbmFibGVkKTogQWRkZWQg YW4gZW1wdHkgbGluZSB0byBpbmNyZWFzZSByZWFkaWJpbGl0eS4KKyAgICAgICAgKFdlYktpdDo6 VGV4dENoZWNrZXI6OnNldEdyYW1tYXJDaGVja2luZ0VuYWJsZWQpOiBEaXR0by4KKyAgICAgICAg KFdlYktpdDo6VGV4dENoZWNrZXI6OmNvbnRpbnVvdXNTcGVsbENoZWNraW5nRW5hYmxlZFN0YXRl Q2hhbmdlZCk6CisgICAgICAgIChXZWJLaXQ6OlRleHRDaGVja2VyOjpncmFtbWFyQ2hlY2tpbmdF bmFibGVkU3RhdGVDaGFuZ2VkKToKKyAgICAgICAgKFdlYktpdDo6VGV4dENoZWNrZXI6OnVuaXF1 ZVNwZWxsRG9jdW1lbnRUYWcpOgorICAgICAgICAoV2ViS2l0OjpUZXh0Q2hlY2tlcjo6Y2xvc2VT cGVsbERvY3VtZW50V2l0aFRhZyk6CisgICAgICAgIChXZWJLaXQ6OlRleHRDaGVja2VyOjpjaGVj a1NwZWxsaW5nT2ZTdHJpbmcpOgorICAgICAgICAoV2ViS2l0OjpUZXh0Q2hlY2tlcjo6Y2hlY2tH cmFtbWFyT2ZTdHJpbmcpOiBSZW1vdmVkIFdlYkNvcmUgbmFtYXNwYWNlIGFzIGl0J3MgYWxyZWFk eSBkZWZpbmVkIGZvciB0aGUgd2hvbGUgZmlsZS4KKyAgICAgICAgKFdlYktpdDo6VGV4dENoZWNr ZXI6OnNwZWxsaW5nVUlJc1Nob3dpbmcpOgorICAgICAgICAoV2ViS2l0OjpUZXh0Q2hlY2tlcjo6 dG9nZ2xlU3BlbGxpbmdVSUlzU2hvd2luZyk6CisgICAgICAgIChXZWJLaXQ6OlRleHRDaGVja2Vy Ojp1cGRhdGVTcGVsbGluZ1VJV2l0aE1pc3NwZWxsZWRXb3JkKToKKyAgICAgICAgKFdlYktpdDo6 VGV4dENoZWNrZXI6OnVwZGF0ZVNwZWxsaW5nVUlXaXRoR3JhbW1hclN0cmluZyk6CisgICAgICAg IChXZWJLaXQ6OlRleHRDaGVja2VyOjpnZXRHdWVzc2VzRm9yV29yZCk6CisgICAgICAgIChXZWJL aXQ6OlRleHRDaGVja2VyOjpsZWFybldvcmQpOgorICAgICAgICAoV2ViS2l0OjpUZXh0Q2hlY2tl cjo6aWdub3JlV29yZCk6CisKIDIwMTItMDktMDIgIFJ5dWFuIENob2kgIDxyeXVhbi5jaG9pQHNh bXN1bmcuY29tPgogCiAgICAgICAgIFtFRkxdW1dLMl0gS2VlcCBhY3RpdmVQb3B1cE1lbnUgdG8g Y2FsbCB2YWx1ZUNoYW5nZWRGb3JQb3B1cE1lbnUoKSBvdXRzaWRlIHNob3dQb3B1cE1lbnUoKQpk aWZmIC0tZ2l0IGEvU291cmNlL1dlYktpdDIvVUlQcm9jZXNzL2d0ay9UZXh0Q2hlY2tlckd0ay5j cHAgYi9Tb3VyY2UvV2ViS2l0Mi9VSVByb2Nlc3MvZ3RrL1RleHRDaGVja2VyR3RrLmNwcAppbmRl eCA0MDVjMGUxLi4yNjdkNDFmIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViS2l0Mi9VSVByb2Nlc3Mv Z3RrL1RleHRDaGVja2VyR3RrLmNwcAorKysgYi9Tb3VyY2UvV2ViS2l0Mi9VSVByb2Nlc3MvZ3Rr L1RleHRDaGVja2VyR3RrLmNwcApAQCAtMjgsNyArMjgsOSBAQAogI2luY2x1ZGUgIlRleHRDaGVj a2VyLmgiCiAKICNpbmNsdWRlICJUZXh0Q2hlY2tlclN0YXRlLmgiCisjaWYgRU5BQkxFKFNQRUxM Q0hFQ0spCiAjaW5jbHVkZSAiV2ViVGV4dENoZWNrZXIuaCIKKyNlbmRpZgogCiB1c2luZyBuYW1l c3BhY2UgV2ViQ29yZTsKICAKQEAgLTM4LDYgKzQwLDcgQEAgc3RhdGljIFRleHRDaGVja2VyU3Rh dGUgdGV4dENoZWNrZXJTdGF0ZTsKIAogY29uc3QgVGV4dENoZWNrZXJTdGF0ZSYgVGV4dENoZWNr ZXI6OnN0YXRlKCkKIHsKKyNpZiBFTkFCTEUoU1BFTExDSEVDSykKICAgICBzdGF0aWMgYm9vbCBk aWRJbml0aWFsaXplU3RhdGUgPSBmYWxzZTsKICAgICBpZiAoZGlkSW5pdGlhbGl6ZVN0YXRlKQog ICAgICAgICByZXR1cm4gdGV4dENoZWNrZXJTdGF0ZTsKQEAgLTQ3LDk0ICs1MCwxMzUgQEAgY29u c3QgVGV4dENoZWNrZXJTdGF0ZSYgVGV4dENoZWNrZXI6OnN0YXRlKCkKICAgICB0ZXh0Q2hlY2tl clN0YXRlLmlzR3JhbW1hckNoZWNraW5nRW5hYmxlZCA9ICBjbGllbnQuZ3JhbW1hckNoZWNraW5n RW5hYmxlZCgpOwogCiAgICAgZGlkSW5pdGlhbGl6ZVN0YXRlID0gdHJ1ZTsKKyNlbmRpZgogCiAg ICAgcmV0dXJuIHRleHRDaGVja2VyU3RhdGU7CiB9CiAgIAogYm9vbCBUZXh0Q2hlY2tlcjo6aXND b250aW51b3VzU3BlbGxDaGVja2luZ0FsbG93ZWQoKQogeworI2lmIEVOQUJMRShTUEVMTENIRUNL KQogICAgIHJldHVybiBXZWJUZXh0Q2hlY2tlcjo6c2hhcmVkKCktPmNsaWVudCgpLmNvbnRpbnVv dXNTcGVsbENoZWNraW5nQWxsb3dlZCgpOworI2Vsc2UKKyAgICByZXR1cm4gZmFsc2U7CisjZW5k aWYKIH0KIAogdm9pZCBUZXh0Q2hlY2tlcjo6c2V0Q29udGludW91c1NwZWxsQ2hlY2tpbmdFbmFi bGVkKGJvb2wgaXNDb250aW51b3VzU3BlbGxDaGVja2luZ0VuYWJsZWQpCiB7CisjaWYgRU5BQkxF KFNQRUxMQ0hFQ0spCiAgICAgaWYgKHN0YXRlKCkuaXNDb250aW51b3VzU3BlbGxDaGVja2luZ0Vu YWJsZWQgPT0gaXNDb250aW51b3VzU3BlbGxDaGVja2luZ0VuYWJsZWQpCiAgICAgICAgIHJldHVy bjsKKwogICAgIHRleHRDaGVja2VyU3RhdGUuaXNDb250aW51b3VzU3BlbGxDaGVja2luZ0VuYWJs ZWQgPSBpc0NvbnRpbnVvdXNTcGVsbENoZWNraW5nRW5hYmxlZDsKICAgICBXZWJUZXh0Q2hlY2tl cjo6c2hhcmVkKCktPmNsaWVudCgpLnNldENvbnRpbnVvdXNTcGVsbENoZWNraW5nRW5hYmxlZChp c0NvbnRpbnVvdXNTcGVsbENoZWNraW5nRW5hYmxlZCk7CisjZW5kaWYKIH0KIAogdm9pZCBUZXh0 Q2hlY2tlcjo6c2V0R3JhbW1hckNoZWNraW5nRW5hYmxlZChib29sIGlzR3JhbW1hckNoZWNraW5n RW5hYmxlZCkKIHsKKyNpZiBFTkFCTEUoU1BFTExDSEVDSykKICAgICBpZiAoc3RhdGUoKS5pc0dy YW1tYXJDaGVja2luZ0VuYWJsZWQgPT0gaXNHcmFtbWFyQ2hlY2tpbmdFbmFibGVkKQogICAgICAg ICByZXR1cm47CisKICAgICB0ZXh0Q2hlY2tlclN0YXRlLmlzR3JhbW1hckNoZWNraW5nRW5hYmxl ZCA9IGlzR3JhbW1hckNoZWNraW5nRW5hYmxlZDsKICAgICBXZWJUZXh0Q2hlY2tlcjo6c2hhcmVk KCktPmNsaWVudCgpLnNldEdyYW1tYXJDaGVja2luZ0VuYWJsZWQoaXNHcmFtbWFyQ2hlY2tpbmdF bmFibGVkKTsKKyNlbmRpZgogfQogCiB2b2lkIFRleHRDaGVja2VyOjpjb250aW51b3VzU3BlbGxD aGVja2luZ0VuYWJsZWRTdGF0ZUNoYW5nZWQoYm9vbCBlbmFibGVkKQogeworI2lmIEVOQUJMRShT UEVMTENIRUNLKQogICAgIHRleHRDaGVja2VyU3RhdGUuaXNDb250aW51b3VzU3BlbGxDaGVja2lu Z0VuYWJsZWQgPSBlbmFibGVkOworI2VuZGlmCiB9CiAKIHZvaWQgVGV4dENoZWNrZXI6OmdyYW1t YXJDaGVja2luZ0VuYWJsZWRTdGF0ZUNoYW5nZWQoYm9vbCBlbmFibGVkKQogeworI2lmIEVOQUJM RShTUEVMTENIRUNLKQogICAgIHRleHRDaGVja2VyU3RhdGUuaXNHcmFtbWFyQ2hlY2tpbmdFbmFi bGVkID0gZW5hYmxlZDsKKyNlbmRpZgogfQogCiBpbnQ2NF90IFRleHRDaGVja2VyOjp1bmlxdWVT cGVsbERvY3VtZW50VGFnKFdlYlBhZ2VQcm94eSogcGFnZSkKIHsKKyNpZiBFTkFCTEUoU1BFTExD SEVDSykKICAgICByZXR1cm4gV2ViVGV4dENoZWNrZXI6OnNoYXJlZCgpLT5jbGllbnQoKS51bmlx dWVTcGVsbERvY3VtZW50VGFnKHBhZ2UpOworI2Vsc2UKKyAgICByZXR1cm4gMDsKKyNlbmRpZgog fQogCiB2b2lkIFRleHRDaGVja2VyOjpjbG9zZVNwZWxsRG9jdW1lbnRXaXRoVGFnKGludDY0X3Qg dGFnKQogeworI2lmIEVOQUJMRShTUEVMTENIRUNLKQogICAgIFdlYlRleHRDaGVja2VyOjpzaGFy ZWQoKS0+Y2xpZW50KCkuY2xvc2VTcGVsbERvY3VtZW50V2l0aFRhZyh0YWcpOworI2VuZGlmCiB9 CiAKIHZvaWQgVGV4dENoZWNrZXI6OmNoZWNrU3BlbGxpbmdPZlN0cmluZyhpbnQ2NF90IHNwZWxs RG9jdW1lbnRUYWcsIGNvbnN0IFVDaGFyKiB0ZXh0LCB1aW50MzJfdCBsZW5ndGgsIGludDMyX3Qm IG1pc3NwZWxsaW5nTG9jYXRpb24sIGludDMyX3QmIG1pc3NwZWxsaW5nTGVuZ3RoKQogeworI2lm IEVOQUJMRShTUEVMTENIRUNLKQogICAgIFdlYlRleHRDaGVja2VyOjpzaGFyZWQoKS0+Y2xpZW50 KCkuY2hlY2tTcGVsbGluZ09mU3RyaW5nKHNwZWxsRG9jdW1lbnRUYWcsIFN0cmluZyh0ZXh0LCBs ZW5ndGgpLCBtaXNzcGVsbGluZ0xvY2F0aW9uLCBtaXNzcGVsbGluZ0xlbmd0aCk7CisjZW5kaWYK IH0KIAotdm9pZCBUZXh0Q2hlY2tlcjo6Y2hlY2tHcmFtbWFyT2ZTdHJpbmcoaW50NjRfdCBzcGVs bERvY3VtZW50VGFnLCBjb25zdCBVQ2hhciogdGV4dCwgdWludDMyX3QgbGVuZ3RoLCBWZWN0b3I8 V2ViQ29yZTo6R3JhbW1hckRldGFpbD4mIGdyYW1tYXJEZXRhaWxzLCBpbnQzMl90JiBiYWRHcmFt bWFyTG9jYXRpb24sIGludDMyX3QmIGJhZEdyYW1tYXJMZW5ndGgpCit2b2lkIFRleHRDaGVja2Vy OjpjaGVja0dyYW1tYXJPZlN0cmluZyhpbnQ2NF90IHNwZWxsRG9jdW1lbnRUYWcsIGNvbnN0IFVD aGFyKiB0ZXh0LCB1aW50MzJfdCBsZW5ndGgsIFZlY3RvcjxHcmFtbWFyRGV0YWlsPiYgZ3JhbW1h ckRldGFpbHMsIGludDMyX3QmIGJhZEdyYW1tYXJMb2NhdGlvbiwgaW50MzJfdCYgYmFkR3JhbW1h ckxlbmd0aCkKIHsKKyNpZiBFTkFCTEUoU1BFTExDSEVDSykKICAgICBXZWJUZXh0Q2hlY2tlcjo6 c2hhcmVkKCktPmNsaWVudCgpLmNoZWNrR3JhbW1hck9mU3RyaW5nKHNwZWxsRG9jdW1lbnRUYWcs IFN0cmluZyh0ZXh0LCBsZW5ndGgpLCBncmFtbWFyRGV0YWlscywgYmFkR3JhbW1hckxvY2F0aW9u LCBiYWRHcmFtbWFyTGVuZ3RoKTsKKyNlbmRpZgogfQogCiBib29sIFRleHRDaGVja2VyOjpzcGVs bGluZ1VJSXNTaG93aW5nKCkKIHsKKyNpZiBFTkFCTEUoU1BFTExDSEVDSykKICAgICByZXR1cm4g V2ViVGV4dENoZWNrZXI6OnNoYXJlZCgpLT5jbGllbnQoKS5zcGVsbGluZ1VJSXNTaG93aW5nKCk7 CisjZWxzZQorICAgIHJldHVybiBmYWxzZTsKKyNlbmRpZgogfQogCiB2b2lkIFRleHRDaGVja2Vy Ojp0b2dnbGVTcGVsbGluZ1VJSXNTaG93aW5nKCkKIHsKKyNpZiBFTkFCTEUoU1BFTExDSEVDSykK ICAgICBXZWJUZXh0Q2hlY2tlcjo6c2hhcmVkKCktPmNsaWVudCgpLnRvZ2dsZVNwZWxsaW5nVUlJ c1Nob3dpbmcoKTsKKyNlbmRpZgogfQogCiB2b2lkIFRleHRDaGVja2VyOjp1cGRhdGVTcGVsbGlu Z1VJV2l0aE1pc3NwZWxsZWRXb3JkKGludDY0X3Qgc3BlbGxEb2N1bWVudFRhZywgY29uc3QgU3Ry aW5nJiBtaXNzcGVsbGVkV29yZCkKIHsKKyNpZiBFTkFCTEUoU1BFTExDSEVDSykKICAgICBXZWJU ZXh0Q2hlY2tlcjo6c2hhcmVkKCktPmNsaWVudCgpLnVwZGF0ZVNwZWxsaW5nVUlXaXRoTWlzc3Bl bGxlZFdvcmQoc3BlbGxEb2N1bWVudFRhZywgbWlzc3BlbGxlZFdvcmQpOworI2VuZGlmCiB9CiAK IHZvaWQgVGV4dENoZWNrZXI6OnVwZGF0ZVNwZWxsaW5nVUlXaXRoR3JhbW1hclN0cmluZyhpbnQ2 NF90IHNwZWxsRG9jdW1lbnRUYWcsIGNvbnN0IFN0cmluZyYgYmFkR3JhbW1hclBocmFzZSwgY29u c3QgR3JhbW1hckRldGFpbCYgZ3JhbW1hckRldGFpbCkKIHsKKyNpZiBFTkFCTEUoU1BFTExDSEVD SykKICAgICBXZWJUZXh0Q2hlY2tlcjo6c2hhcmVkKCktPmNsaWVudCgpLnVwZGF0ZVNwZWxsaW5n VUlXaXRoR3JhbW1hclN0cmluZyhzcGVsbERvY3VtZW50VGFnLCBiYWRHcmFtbWFyUGhyYXNlLCBn cmFtbWFyRGV0YWlsKTsKKyNlbmRpZgogfQogCiB2b2lkIFRleHRDaGVja2VyOjpnZXRHdWVzc2Vz Rm9yV29yZChpbnQ2NF90IHNwZWxsRG9jdW1lbnRUYWcsIGNvbnN0IFN0cmluZyYgd29yZCwgY29u c3QgU3RyaW5nJiBjb250ZXh0LCBWZWN0b3I8U3RyaW5nPiYgZ3Vlc3NlcykKIHsKKyNpZiBFTkFC TEUoU1BFTExDSEVDSykKICAgICBXZWJUZXh0Q2hlY2tlcjo6c2hhcmVkKCktPmNsaWVudCgpLmd1 ZXNzZXNGb3JXb3JkKHNwZWxsRG9jdW1lbnRUYWcsIHdvcmQsIGd1ZXNzZXMpOworI2VuZGlmCiB9 CiAKIHZvaWQgVGV4dENoZWNrZXI6OmxlYXJuV29yZChpbnQ2NF90IHNwZWxsRG9jdW1lbnRUYWcs IGNvbnN0IFN0cmluZyYgd29yZCkKIHsKKyNpZiBFTkFCTEUoU1BFTExDSEVDSykKICAgICBXZWJU ZXh0Q2hlY2tlcjo6c2hhcmVkKCktPmNsaWVudCgpLmxlYXJuV29yZChzcGVsbERvY3VtZW50VGFn LCB3b3JkKTsKKyNlbmRpZgogfQogCiB2b2lkIFRleHRDaGVja2VyOjppZ25vcmVXb3JkKGludDY0 X3Qgc3BlbGxEb2N1bWVudFRhZywgY29uc3QgU3RyaW5nJiB3b3JkKQogeworI2lmIEVOQUJMRShT UEVMTENIRUNLKQogICAgIFdlYlRleHRDaGVja2VyOjpzaGFyZWQoKS0+Y2xpZW50KCkuaWdub3Jl V29yZChzcGVsbERvY3VtZW50VGFnLCB3b3JkKTsKKyNlbmRpZgogfQogCiB9IC8vIG5hbWVzcGFj ZSBXZWJLaXQK