71921 2011-11-09 08:23:07 -0800 Remove use of strcpy in KURL 2011-11-15 11:57:30 -0800 1 1 1 Unclassified WebKit Platform 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED InRadar P2 Normal --- 72387 1 ddkilzer ddkilzer darin koivisto sam webkit.review.bot oldest_to_newest 498985 0 114288 ddkilzer 2011-11-09 08:23:07 -0800 Created attachment 114288 Patch Reviewed by NOBODY (OOPS!). * platform/KURL.cpp: (WebCore::KURL::init): Replace strcat() with strncat(). --- 2 files changed, 14 insertions(+), 2 deletions(-) 498986 1 114288 ddkilzer 2011-11-09 08:24:43 -0800 Comment on attachment 114288 Patch Oops...left a fprintf in there. 498987 2 webkit.review.bot 2011-11-09 08:24:47 -0800 Attachment 114288 did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/WebCore/ChangeLog', u'Source/WebCor..." exit_code: 1 Source/WebCore/ChangeLog:1: ChangeLog entry has no bug number [changelog/bugnumber] [5] Total errors found: 1 in 2 files If any of these errors are false positives, please file a bug against check-webkit-style. 499001 3 114291 ddkilzer 2011-11-09 08:38:46 -0800 Created attachment 114291 Patch v2 Removed fprintf statement. 499002 4 114291 ddkilzer 2011-11-09 08:41:21 -0800 Comment on attachment 114291 Patch v2 Oops. Need to subtract 1 from third argument to make sure the string is null-terminated. 499004 5 114291 ddkilzer 2011-11-09 08:43:05 -0800 Comment on attachment 114291 Patch v2 Nevermind...that's checked by the ASSERT below. 499012 6 ddkilzer 2011-11-09 08:48:11 -0800 (In reply to comment #4) > (From update of attachment 114291 [details]) > Oops. Need to subtract 1 from third argument to make sure the string is null-terminated. Also, that won't cause the string to be NULL-terminated. The strlen(s2) must be less than n for that to hold. 499023 7 114291 kling 2011-11-09 08:58:35 -0800 Comment on attachment 114291 Patch v2 View in context: https://bugs.webkit.org/attachment.cgi?id=114291&action=review > Source/WebCore/ChangeLog:3 > + <http://webkit.org/b/71921> Remove use of strcat in KURL strcpy, not strcat! And a personal style nit, I think it would look better on two lines: Remove use of strcpy in KURL <http://webkit.org/b/71921> > Source/WebCore/platform/KURL.cpp:552 > - strcpy(bufferPos, relStringPos); > + strncpy(bufferPos, relStringPos, parserBufferSize - (bufferPosStart - bufferPos)); This looks backwards, shouldn't it be (bufferPos - bufferPosStart)? 499028 8 ddkilzer 2011-11-09 09:03:20 -0800 (In reply to comment #7) > (From update of attachment 114291 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=114291&action=review > > > Source/WebCore/ChangeLog:3 > > + <http://webkit.org/b/71921> Remove use of strcat in KURL > > strcpy, not strcat! Wow, it's too early. > And a personal style nit, I think it would look better on two lines: > Remove use of strcpy in KURL > <http://webkit.org/b/71921> > > > Source/WebCore/platform/KURL.cpp:552 > > - strcpy(bufferPos, relStringPos); > > + strncpy(bufferPos, relStringPos, parserBufferSize - (bufferPosStart - bufferPos)); > > This looks backwards, shouldn't it be (bufferPos - bufferPosStart)? Yes! 499083 9 114291 darin 2011-11-09 09:48:53 -0800 Comment on attachment 114291 Patch v2 View in context: https://bugs.webkit.org/attachment.cgi?id=114291&action=review > Source/WebCore/platform/KURL.cpp:485 > + const size_t parserBufferSize = base.m_pathEnd + 1 + len + 1; We don’t normally use const like this for local variables. If we did, then bufferPosStart would also be const: const char* bufferPosStart. I suggest just leaving out the const. > Source/WebCore/platform/KURL.cpp:489 > + const char* bufferPosStart = bufferPos; I think bufferStart is the right name for this, not bufferPosStart. 500496 10 ddkilzer 2011-11-10 21:07:37 -0800 (In reply to comment #9) > (From update of attachment 114291 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=114291&action=review > > > Source/WebCore/platform/KURL.cpp:485 > > + const size_t parserBufferSize = base.m_pathEnd + 1 + len + 1; > > We don’t normally use const like this for local variables. If we did, then bufferPosStart would also be const: const char* bufferPosStart. I suggest just leaving out the const. Note that bufferPosStart is also const. Why do we normally leave out const? It's a hint that this value should never be altered within the method, which is exactly what I want. > > Source/WebCore/platform/KURL.cpp:489 > > + const char* bufferPosStart = bufferPos; > > I think bufferStart is the right name for this, not bufferPosStart. Okay. 500500 11 ddkilzer 2011-11-10 21:17:04 -0800 (In reply to comment #10) > (In reply to comment #9) > > (From update of attachment 114291 [details] [details]) > > View in context: https://bugs.webkit.org/attachment.cgi?id=114291&action=review > > > > > Source/WebCore/platform/KURL.cpp:485 > > > + const size_t parserBufferSize = base.m_pathEnd + 1 + len + 1; > > > > We don’t normally use const like this for local variables. If we did, then bufferPosStart would also be const: const char* bufferPosStart. I suggest just leaving out the const. > > Why do we normally leave out const? It's a hint that this value should never be altered within the method, which is exactly what I want. Or to put it another way: If someone came along later and added code that changed parserBufferSize/bufferSize between the time it was declared and the time it was used in strncpy(), that should be an error. Removing the const-ness from the local variable would eliminate this error condition. The same goes for bufferPosStart/bufferStart, which is why it was also made const. 500502 12 114622 ddkilzer 2011-11-10 21:18:43 -0800 Created attachment 114622 Patch v3 500967 13 114622 koivisto 2011-11-11 11:33:11 -0800 Comment on attachment 114622 Patch v3 r=me 500981 14 ddkilzer 2011-11-11 11:46:57 -0800 Committed r99999: <http://trac.webkit.org/changeset/99999> 500986 15 ddkilzer 2011-11-11 11:55:37 -0800 <rdar://problem/6138531> 500987 16 114622 ddkilzer 2011-11-11 11:56:02 -0800 Comment on attachment 114622 Patch v3 Clearing cq flag as this was landed manually. 502176 17 darin 2011-11-14 12:21:31 -0800 (In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > (From update of attachment 114291 [details] [details] [details]) > > > View in context: https://bugs.webkit.org/attachment.cgi?id=114291&action=review > > > > > > > Source/WebCore/platform/KURL.cpp:485 > > > > + const size_t parserBufferSize = base.m_pathEnd + 1 + len + 1; > > > > > > We don’t normally use const like this for local variables. If we did, then bufferPosStart would also be const: const char* bufferPosStart. I suggest just leaving out the const. > > > > Why do we normally leave out const? It's a hint that this value should never be altered within the method, which is exactly what I want. > > Or to put it another way: If someone came along later and added code that changed parserBufferSize/bufferSize between the time it was declared and the time it was used in strncpy(), that should be an error. Removing the const-ness from the local variable would eliminate this error condition. The same goes for bufferPosStart/bufferStart, which is why it was also made const. bufferStart was not made const. The characters it points to are const, but not the pointer. To make the pointer const you would need to write: const char* const bufferStart = bufferPos; The majority of local variables are intended not to be modified after initialized. Yet we in the past we did not choose to put const in the code in all those places. We can head in a new direction, but typically I prefer to do that after a discussion with WebKit as a group, not in a single patch without that discussion. 502905 18 ddkilzer 2011-11-15 07:57:18 -0800 (In reply to comment #17) > bufferStart was not made const. The characters it points to are const, but not the pointer. To make the pointer const you would need to write: > > const char* const bufferStart = bufferPos; Sorry, I was thinking about C-const-ness instead of C++-const-ness when writing this. > The majority of local variables are intended not to be modified after initialized. Yet we in the past we did not choose to put const in the code in all those places. We can head in a new direction, but typically I prefer to do that after a discussion with WebKit as a group, not in a single patch without that discussion. Filed Bug 72387. 503017 19 koivisto 2011-11-15 10:21:19 -0800 (In reply to comment #17) > The majority of local variables are intended not to be modified after initialized. Yet we in the past we did not choose to put const in the code in all those places. We can head in a new direction, but typically I prefer to do that after a discussion with WebKit as a group, not in a single patch without that discussion. That sounds bit dogmatic. I think the test should be whether using const in a particular case clarifies the code or usefully protects against a class of bugs. Do we really need a project-wide direction for this? 503027 20 darin 2011-11-15 10:25:32 -0800 (In reply to comment #19) > I think the test should be whether using const in a particular case clarifies the code or usefully protects against a class of bugs. Sure, lets look at an example if you think there is a case like that. I don’t think there are any. I’ve never seen a const local variable protect against a class of bugs. Or to put it another way, I’ve never fixed a bug and thought “that never would have happened if this local variable was const”. > Do we really need a project-wide direction for this? I think we do. It’s confusing to see const in one case and not see it in another nearly identical case while looking at multiple functions doing similar things. It’s similar to other seemingly trivial style decisions in that consistency makes it easier to concentrate on meaningful differences in the code. 503089 21 koivisto 2011-11-15 11:22:20 -0800 (In reply to comment #20) > (In reply to comment #19) > > I think the test should be whether using const in a particular case clarifies the code or usefully protects against a class of bugs. > > Sure, lets look at an example if you think there is a case like that. I don’t think there are any. I’ve never seen a const local variable protect against a class of bugs. Or to put it another way, I’ve never fixed a bug and thought “that never would have happened if this local variable was const”. I think any code that uses more than a few variables of the same type would benefit from marking the ones that are logically constant (start/end pointers and similar) as const to document the intentions. For example the code discussed in this bug would benefit from making bufferStart, baseString and possibly some others const. Currently it is quite non-obvious which of the many variables the code is actually supposed to be modifying. This is the "clarifies the code" case which I think is not uncommon. It will also make the compiler warn if you violate these intentions (and at least make you think if they need to be changed). For example modifying bufferStart/bufferSize over the course of this algorithm would be a bug. If the code in question calls functions that return values in arguments accidental modification may be particularly hard to see. I didn't search for a good example in WebKit, don't know if it exist. 503095 22 darin 2011-11-15 11:33:58 -0800 (In reply to comment #21) > I think any code that uses more than a few variables of the same type would benefit from marking the ones that are logically constant (start/end pointers and similar) as const to document the intentions. OK. > It will also make the compiler warn if you violate these intentions (and at least make you think if they need to be changed). For example modifying bufferStart/bufferSize over the course of this algorithm would be a bug. I don’t think this has happened in practice, although I could be wrong. > If the code in question calls functions that return values in arguments accidental modification may be particularly hard to see. I didn't search for a good example in WebKit, don't know if it exist. Pretty sure it does not. 503119 23 koivisto 2011-11-15 11:56:43 -0800 (In reply to comment #22) > I don’t think this has happened in practice, although I could be wrong. Personally I make errors of all sorts as I write code, occasionally I think from this class too. Testing generally reveals them well before they land to WebKit in any case, but using tools like const might catch some of them early and so speed up the process. It seems strange to require removing them before landing as there is obvious harm (and there is the possible documentation benefit). 503120 24 koivisto 2011-11-15 11:57:30 -0800 I meant "no obvious harm" 114288 2011-11-09 08:23:07 -0800 2011-11-09 08:38:25 -0800 Patch 20111109082306.patch text/plain 2162 ddkilzer U3VidmVyc2lvbiBSZXZpc2lvbjogOTk1NzUKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL0No YW5nZUxvZyBiL1NvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwppbmRleCBlMmZmYzIwYjIxOWIyYjU1 NDczZWYzMmVhNWQyYWUxNzk0ZTIxN2MzLi44Y2I1NWNlYjBkYWM4ZWNjNTg4NGY2NjNhODMwOWZm ZmZmMDc0M2I4IDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKKysrIGIvU291 cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTIgQEAKKzIwMTEtMTEtMDkgIERhdmlk IEtpbHplciAgPGRka2lsemVyQGFwcGxlLmNvbT4KKworICAgICAgICA8aHR0cDovL3dlYmtpdC5v cmcvYi9OTk5OTj4gUmVtb3ZlIHVzZSBvZiBzdHJjYXQgaW4gS1VSTAorCisgICAgICAgIFJldmll d2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgICogcGxhdGZvcm0vS1VSTC5jcHA6Cisg ICAgICAgIChXZWJDb3JlOjpLVVJMOjppbml0KTogUmVwbGFjZSBzdHJjYXQoKSB3aXRoIHN0cm5j YXQoKS4KKwogMjAxMS0xMS0wOCAgQW5kcmV5IEtvc3lha292ICA8Y2FzZXFAY2hyb21pdW0ub3Jn PgogCiAgICAgICAgIFdlYiBJbnNwZWN0b3I6IFtFeHRlbnNpb24gQVBJXVtDaHJvbWl1bV0gaW5q ZWN0ZWQgZXh0ZW5zaW9uIEFQSSBuZWVkcyB0byByZXR1cm4gYW4gb2JqZWN0CmRpZmYgLS1naXQg YS9Tb3VyY2UvV2ViQ29yZS9wbGF0Zm9ybS9LVVJMLmNwcCBiL1NvdXJjZS9XZWJDb3JlL3BsYXRm b3JtL0tVUkwuY3BwCmluZGV4IDA1OWZiMmIxNTg3YWVmMGIyNjExYmEwZmNjYmM3NjY1ZTIxY2Ex MTguLjg4MzVhMDRhNWE5MWIxOTc5N2Q5ZTE0Y2RjNzk2YTE0ZGE0N2MxY2EgMTAwNjQ0Ci0tLSBh L1NvdXJjZS9XZWJDb3JlL3BsYXRmb3JtL0tVUkwuY3BwCisrKyBiL1NvdXJjZS9XZWJDb3JlL3Bs YXRmb3JtL0tVUkwuY3BwCkBAIC00ODIsOSArNDgyLDExIEBAIHZvaWQgS1VSTDo6aW5pdChjb25z dCBLVVJMJiBiYXNlLCBjb25zdCBTdHJpbmcmIHJlbGF0aXZlLCBjb25zdCBUZXh0RW5jb2Rpbmcm IGVuCiAgICAgICAgICAgICAgICAgLy8gbXVzdCBiZSByZWxhdGl2ZS1wYXRoIHJlZmVyZW5jZQog CiAgICAgICAgICAgICAgICAgLy8gQmFzZSBwYXJ0IHBsdXMgcmVsYXRpdmUgcGFydCBwbHVzIG9u ZSBwb3NzaWJsZSBzbGFzaCBhZGRlZCBpbiBiZXR3ZWVuIHBsdXMgdGVybWluYXRpbmcgXDAgYnl0 ZS4KLSAgICAgICAgICAgICAgICBwYXJzZUJ1ZmZlci5yZXNpemUoYmFzZS5tX3BhdGhFbmQgKyAx ICsgbGVuICsgMSk7CisgICAgICAgICAgICAgICAgY29uc3Qgc2l6ZV90IHBhcnNlckJ1ZmZlclNp emUgPSBiYXNlLm1fcGF0aEVuZCArIDEgKyBsZW4gKyAxOworICAgICAgICAgICAgICAgIHBhcnNl QnVmZmVyLnJlc2l6ZShwYXJzZXJCdWZmZXJTaXplKTsKIAogICAgICAgICAgICAgICAgIGNoYXIq IGJ1ZmZlclBvcyA9IHBhcnNlQnVmZmVyLmRhdGEoKTsKKyAgICAgICAgICAgICAgICBjb25zdCBj aGFyKiBidWZmZXJQb3NTdGFydCA9IGJ1ZmZlclBvczsKIAogICAgICAgICAgICAgICAgIC8vIGZp cnN0IGNvcHkgZXZlcnl0aGluZyBiZWZvcmUgdGhlIHBhdGggZnJvbSB0aGUgYmFzZQogICAgICAg ICAgICAgICAgIHVuc2lnbmVkIGJhc2VMZW5ndGggPSBiYXNlLm1fc3RyaW5nLmxlbmd0aCgpOwpA QCAtNTQ3LDcgKzU0OSw4IEBAIHZvaWQgS1VSTDo6aW5pdChjb25zdCBLVVJMJiBiYXNlLCBjb25z dCBTdHJpbmcmIHJlbGF0aXZlLCBjb25zdCBUZXh0RW5jb2RpbmcmIGVuCiAKICAgICAgICAgICAg ICAgICAvLyBhbGwgZG9uZSB3aXRoIHRoZSBwYXRoIHdvcmssIG5vdyBjb3B5IGFueSByZW1haW5k ZXIKICAgICAgICAgICAgICAgICAvLyBvZiB0aGUgcmVsYXRpdmUgcmVmZXJlbmNlOyB0aGlzIHdp bGwgYWxzbyBhZGQgYSBudWxsIHRlcm1pbmF0b3IKLSAgICAgICAgICAgICAgICBzdHJjcHkoYnVm ZmVyUG9zLCByZWxTdHJpbmdQb3MpOworICAgICAgICAgICAgICAgIHN0cm5jcHkoYnVmZmVyUG9z LCByZWxTdHJpbmdQb3MsIHBhcnNlckJ1ZmZlclNpemUgLSAoYnVmZmVyUG9zU3RhcnQgLSBidWZm ZXJQb3MpKTsKK2ZwcmludGYoc3RkZXJyLCAiPDw8PDwgc3RybmNweSBjYWxsZWQgPj4+Pj5cbiIp OwogCiAgICAgICAgICAgICAgICAgcGFyc2UocGFyc2VCdWZmZXIuZGF0YSgpLCAwKTsKIAo= 114291 2011-11-09 08:38:46 -0800 2011-11-10 21:18:39 -0800 Patch v2 bug-71921-20111109083845.patch text/plain 2112 ddkilzer U3VidmVyc2lvbiBSZXZpc2lvbjogOTk1NzUKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL0No YW5nZUxvZyBiL1NvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwppbmRleCBlMmZmYzIwYjIxOWIyYjU1 NDczZWYzMmVhNWQyYWUxNzk0ZTIxN2MzLi4zMTYxNDYwOTZjMjM1ZTlhOTZmOTVjMTZmZTMyOTVj NmUxYjIyYzQ4IDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKKysrIGIvU291 cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTIgQEAKKzIwMTEtMTEtMDkgIERhdmlk IEtpbHplciAgPGRka2lsemVyQGFwcGxlLmNvbT4KKworICAgICAgICA8aHR0cDovL3dlYmtpdC5v cmcvYi83MTkyMT4gUmVtb3ZlIHVzZSBvZiBzdHJjYXQgaW4gS1VSTAorCisgICAgICAgIFJldmll d2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgICogcGxhdGZvcm0vS1VSTC5jcHA6Cisg ICAgICAgIChXZWJDb3JlOjpLVVJMOjppbml0KTogUmVwbGFjZSBzdHJjYXQoKSB3aXRoIHN0cm5j YXQoKS4KKwogMjAxMS0xMS0wOCAgQW5kcmV5IEtvc3lha292ICA8Y2FzZXFAY2hyb21pdW0ub3Jn PgogCiAgICAgICAgIFdlYiBJbnNwZWN0b3I6IFtFeHRlbnNpb24gQVBJXVtDaHJvbWl1bV0gaW5q ZWN0ZWQgZXh0ZW5zaW9uIEFQSSBuZWVkcyB0byByZXR1cm4gYW4gb2JqZWN0CmRpZmYgLS1naXQg YS9Tb3VyY2UvV2ViQ29yZS9wbGF0Zm9ybS9LVVJMLmNwcCBiL1NvdXJjZS9XZWJDb3JlL3BsYXRm b3JtL0tVUkwuY3BwCmluZGV4IDA1OWZiMmIxNTg3YWVmMGIyNjExYmEwZmNjYmM3NjY1ZTIxY2Ex MTguLmQ3N2IyNmZiYTYyNzA0MjAwOTAzMDJkNGYyNGUxZDQwODI0YmE5MTIgMTAwNjQ0Ci0tLSBh L1NvdXJjZS9XZWJDb3JlL3BsYXRmb3JtL0tVUkwuY3BwCisrKyBiL1NvdXJjZS9XZWJDb3JlL3Bs YXRmb3JtL0tVUkwuY3BwCkBAIC00ODIsOSArNDgyLDExIEBAIHZvaWQgS1VSTDo6aW5pdChjb25z dCBLVVJMJiBiYXNlLCBjb25zdCBTdHJpbmcmIHJlbGF0aXZlLCBjb25zdCBUZXh0RW5jb2Rpbmcm IGVuCiAgICAgICAgICAgICAgICAgLy8gbXVzdCBiZSByZWxhdGl2ZS1wYXRoIHJlZmVyZW5jZQog CiAgICAgICAgICAgICAgICAgLy8gQmFzZSBwYXJ0IHBsdXMgcmVsYXRpdmUgcGFydCBwbHVzIG9u ZSBwb3NzaWJsZSBzbGFzaCBhZGRlZCBpbiBiZXR3ZWVuIHBsdXMgdGVybWluYXRpbmcgXDAgYnl0 ZS4KLSAgICAgICAgICAgICAgICBwYXJzZUJ1ZmZlci5yZXNpemUoYmFzZS5tX3BhdGhFbmQgKyAx ICsgbGVuICsgMSk7CisgICAgICAgICAgICAgICAgY29uc3Qgc2l6ZV90IHBhcnNlckJ1ZmZlclNp emUgPSBiYXNlLm1fcGF0aEVuZCArIDEgKyBsZW4gKyAxOworICAgICAgICAgICAgICAgIHBhcnNl QnVmZmVyLnJlc2l6ZShwYXJzZXJCdWZmZXJTaXplKTsKIAogICAgICAgICAgICAgICAgIGNoYXIq IGJ1ZmZlclBvcyA9IHBhcnNlQnVmZmVyLmRhdGEoKTsKKyAgICAgICAgICAgICAgICBjb25zdCBj aGFyKiBidWZmZXJQb3NTdGFydCA9IGJ1ZmZlclBvczsKIAogICAgICAgICAgICAgICAgIC8vIGZp cnN0IGNvcHkgZXZlcnl0aGluZyBiZWZvcmUgdGhlIHBhdGggZnJvbSB0aGUgYmFzZQogICAgICAg ICAgICAgICAgIHVuc2lnbmVkIGJhc2VMZW5ndGggPSBiYXNlLm1fc3RyaW5nLmxlbmd0aCgpOwpA QCAtNTQ3LDcgKzU0OSw3IEBAIHZvaWQgS1VSTDo6aW5pdChjb25zdCBLVVJMJiBiYXNlLCBjb25z dCBTdHJpbmcmIHJlbGF0aXZlLCBjb25zdCBUZXh0RW5jb2RpbmcmIGVuCiAKICAgICAgICAgICAg ICAgICAvLyBhbGwgZG9uZSB3aXRoIHRoZSBwYXRoIHdvcmssIG5vdyBjb3B5IGFueSByZW1haW5k ZXIKICAgICAgICAgICAgICAgICAvLyBvZiB0aGUgcmVsYXRpdmUgcmVmZXJlbmNlOyB0aGlzIHdp bGwgYWxzbyBhZGQgYSBudWxsIHRlcm1pbmF0b3IKLSAgICAgICAgICAgICAgICBzdHJjcHkoYnVm ZmVyUG9zLCByZWxTdHJpbmdQb3MpOworICAgICAgICAgICAgICAgIHN0cm5jcHkoYnVmZmVyUG9z LCByZWxTdHJpbmdQb3MsIHBhcnNlckJ1ZmZlclNpemUgLSAoYnVmZmVyUG9zU3RhcnQgLSBidWZm ZXJQb3MpKTsKIAogICAgICAgICAgICAgICAgIHBhcnNlKHBhcnNlQnVmZmVyLmRhdGEoKSwgMCk7 CiAK 114622 2011-11-10 21:18:43 -0800 2011-11-11 11:56:02 -0800 Patch v3 bug-71921-20111110211842.patch text/plain 2037 ddkilzer U3VidmVyc2lvbiBSZXZpc2lvbjogOTk5MDcKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL0No YW5nZUxvZyBiL1NvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwppbmRleCBlMGYxMWNkZDRlNzQyOGEx NGY5NzM5N2EwZjJhOTIyZjM0M2Y3YTZkLi5iZjI0NzE3NDdkMDM1MzA5ZTlkNjYwMGJkNzNmZjY0 ODFlNTk2MWE2IDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViQ29yZS9DaGFuZ2VMb2cKKysrIGIvU291 cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTIgQEAKKzIwMTEtMTEtMTAgIERhdmlk IEtpbHplciAgPGRka2lsemVyQGFwcGxlLmNvbT4KKworICAgICAgICA8aHR0cDovL3dlYmtpdC5v cmcvYi83MTkyMT4gUmVtb3ZlIHVzZSBvZiBzdHJjcHkgaW4gS1VSTAorCisgICAgICAgIFJldmll d2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgICogcGxhdGZvcm0vS1VSTC5jcHA6Cisg ICAgICAgIChXZWJDb3JlOjpLVVJMOjppbml0KTogUmVwbGFjZSBzdHJjcHkoKSB3aXRoIHN0cm5j cHkoKS4KKwogMjAxMS0xMS0xMCAgRGVhbiBKYWNrc29uICA8ZGlub0BhcHBsZS5jb20+CiAKICAg ICAgICAgUmVtb3ZlIGVmZmVjdEJvdW5kaW5nQm94TW9kZSBmcm9tIENTUyBGaWx0ZXJzCmRpZmYg LS1naXQgYS9Tb3VyY2UvV2ViQ29yZS9wbGF0Zm9ybS9LVVJMLmNwcCBiL1NvdXJjZS9XZWJDb3Jl L3BsYXRmb3JtL0tVUkwuY3BwCmluZGV4IDA1OWZiMmIxNTg3YWVmMGIyNjExYmEwZmNjYmM3NjY1 ZTIxY2ExMTguLmFkOGY4ZDhlNmJmNjRkZTVlMGY5YWVlMDJjZGI1MDBhYzg1YzYwMzQgMTAwNjQ0 Ci0tLSBhL1NvdXJjZS9XZWJDb3JlL3BsYXRmb3JtL0tVUkwuY3BwCisrKyBiL1NvdXJjZS9XZWJD b3JlL3BsYXRmb3JtL0tVUkwuY3BwCkBAIC00ODIsOSArNDgyLDExIEBAIHZvaWQgS1VSTDo6aW5p dChjb25zdCBLVVJMJiBiYXNlLCBjb25zdCBTdHJpbmcmIHJlbGF0aXZlLCBjb25zdCBUZXh0RW5j b2RpbmcmIGVuCiAgICAgICAgICAgICAgICAgLy8gbXVzdCBiZSByZWxhdGl2ZS1wYXRoIHJlZmVy ZW5jZQogCiAgICAgICAgICAgICAgICAgLy8gQmFzZSBwYXJ0IHBsdXMgcmVsYXRpdmUgcGFydCBw bHVzIG9uZSBwb3NzaWJsZSBzbGFzaCBhZGRlZCBpbiBiZXR3ZWVuIHBsdXMgdGVybWluYXRpbmcg XDAgYnl0ZS4KLSAgICAgICAgICAgICAgICBwYXJzZUJ1ZmZlci5yZXNpemUoYmFzZS5tX3BhdGhF bmQgKyAxICsgbGVuICsgMSk7CisgICAgICAgICAgICAgICAgY29uc3Qgc2l6ZV90IGJ1ZmZlclNp emUgPSBiYXNlLm1fcGF0aEVuZCArIDEgKyBsZW4gKyAxOworICAgICAgICAgICAgICAgIHBhcnNl QnVmZmVyLnJlc2l6ZShidWZmZXJTaXplKTsKIAogICAgICAgICAgICAgICAgIGNoYXIqIGJ1ZmZl clBvcyA9IHBhcnNlQnVmZmVyLmRhdGEoKTsKKyAgICAgICAgICAgICAgICBjb25zdCBjaGFyKiBi dWZmZXJTdGFydCA9IGJ1ZmZlclBvczsKIAogICAgICAgICAgICAgICAgIC8vIGZpcnN0IGNvcHkg ZXZlcnl0aGluZyBiZWZvcmUgdGhlIHBhdGggZnJvbSB0aGUgYmFzZQogICAgICAgICAgICAgICAg IHVuc2lnbmVkIGJhc2VMZW5ndGggPSBiYXNlLm1fc3RyaW5nLmxlbmd0aCgpOwpAQCAtNTQ3LDcg KzU0OSw3IEBAIHZvaWQgS1VSTDo6aW5pdChjb25zdCBLVVJMJiBiYXNlLCBjb25zdCBTdHJpbmcm IHJlbGF0aXZlLCBjb25zdCBUZXh0RW5jb2RpbmcmIGVuCiAKICAgICAgICAgICAgICAgICAvLyBh bGwgZG9uZSB3aXRoIHRoZSBwYXRoIHdvcmssIG5vdyBjb3B5IGFueSByZW1haW5kZXIKICAgICAg ICAgICAgICAgICAvLyBvZiB0aGUgcmVsYXRpdmUgcmVmZXJlbmNlOyB0aGlzIHdpbGwgYWxzbyBh ZGQgYSBudWxsIHRlcm1pbmF0b3IKLSAgICAgICAgICAgICAgICBzdHJjcHkoYnVmZmVyUG9zLCBy ZWxTdHJpbmdQb3MpOworICAgICAgICAgICAgICAgIHN0cm5jcHkoYnVmZmVyUG9zLCByZWxTdHJp bmdQb3MsIGJ1ZmZlclNpemUgLSAoYnVmZmVyUG9zIC0gYnVmZmVyU3RhcnQpKTsKIAogICAgICAg ICAgICAgICAgIHBhcnNlKHBhcnNlQnVmZmVyLmRhdGEoKSwgMCk7CiAK