Summary: | Fix the behavior of reflecting IDL attributes of type unsigned long | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Chris Dumez <cdumez> | ||||||
Component: | History | Assignee: | Chris Dumez <cdumez> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | cmarcelo, commit-queue, darin, esprehn+autocc, gyuyoung.kim, kangil.han, rniwa, sam | ||||||
Priority: | P2 | Keywords: | WebExposed | ||||||
Version: | WebKit Nightly Build | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Attachments: |
|
Description
Chris Dumez
2016-02-26 20:47:29 PST
Firefox and Chrome match the specification. Created attachment 272399 [details]
Patch
Comment on attachment 272399 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=272399&action=review > Source/WebCore/html/parser/HTMLParserIdioms.h:123 > + ASSERT(value > 0 && value <= 2147483647); Can we use 0x7FFFFFFF instead and define a static const somewhere? e.g. static const MaxHTMLNonNegativeNumber = 0x7FFFFFFF. (In reply to comment #3) > Comment on attachment 272399 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=272399&action=review > > > Source/WebCore/html/parser/HTMLParserIdioms.h:123 > > + ASSERT(value > 0 && value <= 2147483647); > > Can we use 0x7FFFFFFF instead and define a static const somewhere? > e.g. static const MaxHTMLNonNegativeNumber = 0x7FFFFFFF. I find 2147483647 a lot more readable than 0x7FFFFFFF personally. It also matches what is in the HTML and the Web IDL specs. (In reply to comment #4) > (In reply to comment #3) > > Comment on attachment 272399 [details] > > Patch > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=272399&action=review > > > > > Source/WebCore/html/parser/HTMLParserIdioms.h:123 > > > + ASSERT(value > 0 && value <= 2147483647); > > > > Can we use 0x7FFFFFFF instead and define a static const somewhere? > > e.g. static const MaxHTMLNonNegativeNumber = 0x7FFFFFFF. > > I find 2147483647 a lot more readable than 0x7FFFFFFF personally. It also > matches what is in the HTML and the Web IDL specs. Really!? 2147483647 doesn't tell me anything about why it's significant whereas 0x7FFFFFFF would tell us exactly why that value is picked. Created attachment 272405 [details]
Patch
Comment on attachment 272405 [details] Patch Clearing flags on attachment: 272405 Committed r197237: <http://trac.webkit.org/changeset/197237> All reviewed patches have been landed. Closing bug. (In reply to comment #4) > I find 2147483647 a lot more readable than 0x7FFFFFFF personally. It also > matches what is in the HTML and the Web IDL specs. I am not sure what you mean by readable, but I think that’s not really possible. For example, what if I wrote this: 2147383647 Would you be able to spot that value is not 2^31-1? It’s true that the same problem can happen with: 0x7FFFFFF But I, at least, can see the difference, whereas with the decimal number it’s just always unsafe, could have one digit wrong and we’d never see it. |