Bug 221767
| Summary: | Investigate creation and use of checked_objc_cast<> | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | David Kilzer (:ddkilzer) <ddkilzer> |
| Component: | Web Template Framework | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | darin, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| See Also: | https://bugs.webkit.org/show_bug.cgi?id=221428 | ||
David Kilzer (:ddkilzer)
Investigate creation and use of checked_objc_cast<>.
Via Darin Adler (paraphrasing): The dynamic_objc_cast<> method exists, but there may be some cases in WebKit where we actually want a checked_objc_cast<> method, similar to checked_cf_cast<>.
In a nutshell:
- Use checked_objc_cast<> if we always expect the same type of object (or nil), and it's obviously incorrect if a different (non-nil) object is referenced.
- Use dynamic_objc_cast<> if we're checking for a particular type, but it's not fatal if we get a different type. The result of dynamic_objc_cast<> should always be nil-checked.
See also the discussion in Bug 221428 Comment #0 for the differences between checked_cf_cast<> and dynamic_cf_cast<>:
<https://bugs.webkit.org/show_bug.cgi?id=221428#c0>
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Darin Adler
Because Objective-C has built in predictable behavior for nil, it’s probably a little less common to *need* the stricter checking than in CF code and checked_cf_cast, but I think I spotted a few cases where the runtime check and abort of the "checked" version would be better than what we have right now.
Radar WebKit Bug Importer
<rdar://problem/74488150>