[Webkit-unassigned] [Bug 70107] Custom written CSS lexer

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Dec 12 13:09:50 PST 2011


https://bugs.webkit.org/show_bug.cgi?id=70107


Oliver Hunt <oliver at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #118748|review?                     |review-
               Flag|                            |




--- Comment #11 from Oliver Hunt <oliver at apple.com>  2011-12-12 13:09:50 PST ---
(From update of attachment 118748)
View in context: https://bugs.webkit.org/attachment.cgi?id=118748&action=review

There seems to be a lot of code in this that assumes null-termination of all strings passed to the lexer -- is this guaranteed?  For instance if i do var foo = "some big string"; someElement.style=foo.substring(2, 8);  (not sure if this exact statement is valid), we may return a StringImpl that is referencing the middle of another string so null termination won't be guaranteed.

At the very least i'd like assertions that m_data never exceeds the buffer length.

> Source/WebCore/css/CSSParser.cpp:7388
> +    return chr | 0x20;

Can you add an assertion that chr is in fact an ascii letter?

> Source/WebCore/css/CSSParser.cpp:7394
> +        || (data[0] == '\\' && isCSSEscape(data[1]));

How do we guarantee data is at least 2 characters long?

> Source/WebCore/css/CSSParser.cpp:7430
> +        } while (isASCIIHexDigit(*data) && --length);

I'd like assertions that data doesn't extend beyond the end of the buffer.

> Source/WebCore/css/CSSParser.cpp:7533
> +        if (UNLIKELY(*m_data == quote)) {
> +            // String parsing is done.
> +            ++m_data;
> +            return;
> +        }

What happens if we have an unterminated string? afaict we just walk off the end of the buffer.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list