Bug 144440
| Summary: | Introduce UniquePropertyID class instead of using StringImpl* as uid | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Yusuke Suzuki <ysuzuki> |
| Component: | JavaScriptCore | Assignee: | Yusuke Suzuki <ysuzuki> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | Normal | CC: | darin, fpizlo, ggaren |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | 144438 | ||
| Bug Blocks: | |||
Yusuke Suzuki
To prevent the symbolized StringImpl* with the other string in their contents accidentally, I'm now planning to introduce a new class such as UniquePropertyID.
In UniquePropertyID, we prohibit comparison in their contents. Pointer comparison is only allowed. This is the replacement to StringImpl* uid usage.
The typical implementaion is the following...
class UniquePropertyID : private StringImpl {
using existingSymbolAwareHash;
using symbolAwareHash;
using isSymbol;
StringImpl* publicName()
{
return isSymbol() ? nullptr : this;
}
// Factory functions from StringImpl*.
// ...
};
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Yusuke Suzuki
Hm, but, if these use cases are rare enough, we can go without this fix.
Yusuke Suzuki
After considering about it, I think this case is a little bit rare. Because when using StringImpl* would be used for Identifier, it is already atomized / symbolized by Identifier class. So places we need to take care is when comparing StringImpl* (which is used as uid) and the other strings .
Yusuke Suzuki
*** This bug has been marked as a duplicate of bug 144848 ***