WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
161796
HashMapImpl needs to m_buffer.clear() in its constructor
https://bugs.webkit.org/show_bug.cgi?id=161796
Summary
HashMapImpl needs to m_buffer.clear() in its constructor
Filip Pizlo
Reported
2016-09-09 08:55:42 PDT
Patch forthcoming.
Attachments
possible patch
(2.31 KB, patch)
2016-09-09 09:03 PDT
,
Filip Pizlo
keith_miller
: review+
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Ryan Haddad
Comment 1
2016-09-09 09:02:26 PDT
***
Bug 161797
has been marked as a duplicate of this bug. ***
Filip Pizlo
Comment 2
2016-09-09 09:03:59 PDT
Created
attachment 288405
[details]
possible patch
WebKit Commit Bot
Comment 3
2016-09-09 09:37:16 PDT
Attachment 288405
[details]
did not pass style-queue: ERROR: Source/JavaScriptCore/runtime/AuxiliaryBarrier.h:40: Should be indented on a separate line, with the colon or comma first on that line. [whitespace/indent] [4] Total errors found: 1 in 2 files If any of these errors are false positives, please file a bug against check-webkit-style.
Keith Miller
Comment 4
2016-09-09 09:50:30 PDT
Comment on
attachment 288405
[details]
possible patch r=me.
Filip Pizlo
Comment 5
2016-09-09 09:52:40 PDT
Landed in
https://trac.webkit.org/changeset/205746
Mark Lam
Comment 6
2016-09-09 10:07:28 PDT
Comment on
attachment 288405
[details]
possible patch View in context:
https://bugs.webkit.org/attachment.cgi?id=288405&action=review
> Source/JavaScriptCore/ChangeLog:3 > + HashMapImpl needs to m_buffer.clear() in its constructor
It's strange that the bug/patch description doesn't seem to match what is being changed. Am I missing some context here?
Darin Adler
Comment 7
2016-10-05 10:32:26 PDT
Comment on
attachment 288405
[details]
possible patch View in context:
https://bugs.webkit.org/attachment.cgi?id=288405&action=review
> Source/JavaScriptCore/ChangeLog:10 > + This is the second time that I'm fixing a bug because AuxiliaryBarrier does not initialize > + itself. That seemed like a good idea because maybe sometimes the user knows better how to > + initialize it. But, it's not worth it if it's a constant source of bugs.
One design that allows you to keep the optimization but make the class less error-prone to use is to add a default constructor and a separate constructor that does not initialize that you can invoke explicitly. Something like this: enum DoNotInitializeType { DoNotInitialize }; class AuxiliaryBarrier { public: AuxiliaryBarrier(); explicit AuxiliaryBarrier(DoNotInitializeType); ... };
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug