WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
181050
Cleanup: Dereference value of optional directly instead of using checked value in WebCore::subdivide()
https://bugs.webkit.org/show_bug.cgi?id=181050
Summary
Cleanup: Dereference value of optional directly instead of using checked valu...
Daniel Bates
Reported
2017-12-20 11:34:51 PST
Cleanup: Deference value of optional directly instead of using checked value in WebCore::subdivide().
Attachments
Patch
(2.76 KB, patch)
2017-12-20 11:41 PST
,
Daniel Bates
simon.fraser
: review+
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Daniel Bates
Comment 1
2017-12-20 11:41:25 PST
Created
attachment 329940
[details]
Patch
Simon Fraser (smfr)
Comment 2
2017-12-20 12:00:50 PST
Comment on
attachment 329940
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=329940&action=review
> Source/WebCore/ChangeLog:3 > + Cleanup: Deference value of optional directly instead of using checked value in WebCore::subdivide()
Dereference
Daniel Bates
Comment 3
2017-12-20 12:05:03 PST
Committed
r226195
: <
https://trac.webkit.org/changeset/226195
>
Radar WebKit Bug Importer
Comment 4
2017-12-20 12:06:14 PST
<
rdar://problem/36161451
>
Darin Adler
Comment 5
2018-01-07 22:20:57 PST
This does not seem right. Not harmful, but not helpful either. I thought that std::optional::operator* and std::optional::value are supposed to have identical semantics. The choice of which one to use should be about clarity, not runtime checking cost. Looking at our Optional.h header, in fact it seems that currently operator* has the assertion and value does not. Which seems quite peculiar. Not sure why. JF?
JF Bastien
Comment 6
2018-01-08 09:18:43 PST
(In reply to Darin Adler from
comment #5
)
> This does not seem right. Not harmful, but not helpful either. > > I thought that std::optional::operator* and std::optional::value are > supposed to have identical semantics. The choice of which one to use should > be about clarity, not runtime checking cost. > > Looking at our Optional.h header, in fact it seems that currently operator* > has the assertion and value does not. Which seems quite peculiar. Not sure > why. > > JF?
They don't have the same semantics when the optional doesn't contain a value. operator*() says: Requires: *this contains a value. Therefore using it when the optional contains no value is UB. A valid implementation could throw or abort in these cases, or just return whatever random thing the memory contained. Whereas value() has no requires clause, and instead says: Effects: Equivalent to: return bool(*this) ? *val : throw bad_optional_access(); Without exception support, the right thing to do in value() is to abort. So I agree with Dan that it's sufficient to use operator* when you've proven that a value is indeed contained. I'm not sure it's more efficient: if we've proven it then presumably the compiler can eliminate the value check: since it's the same thing, that check should just go away, I'd look at the assembly. If the compiler doesn't do it I'd say it's a bug, or it hasn't been proven sufficiently :-) Maybe our implementation of optional should be changed to abort always on bad usage? Another pattern that's nice is unwrapping the value and then just using that. Not sure that works here? Maybe value_or() would be appropriate (though seems not either...).
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