ASSERTION FAILED: name[0] == '@' && length >= 2 in WebCore::CSSTokenizer::detectAtToken

Source/core/css/CSSTokenizer-in.cpp

Index: Source/core/css/CSSTokenizer-in.cpp
diff --git a/Source/core/css/CSSTokenizer-in.cpp b/Source/core/css/CSSTokenizer-in.cpp
index 58a30bc4a0b9ac7c2cd3b44e3ae892e1fb3e3d39..03c2945643e5f522cc75c0ec3df13e4bfd440f3a 100644
--- a/Source/core/css/CSSTokenizer-in.cpp
+++ b/Source/core/css/CSSTokenizer-in.cpp
@@ -1481,7 +1481,7 @@ restartAfterComment:
             m_token = ATKEYWORD;
             ++result;
             parseIdentifier(result, resultString, hasEscape);
-            detectAtToken<SrcCharacterType>(result - tokenStart<SrcCharacterType>(), hasEscape);
+            detectAtToken<SrcCharacterType>(resultString.length() + 1, hasEscape);

[Julien - ping for review, 2014/05/08 15:26:29]

This seems like a big footgun that you are neutering in one case, which is good
but IMO falls too short as we will fight this problem again in the future.

Looking at the rest of the code, there are other callers to parseIdentifier (and
other code paths that could follow when tokenizing) that are also doing pointer
arithmetic. Are they not also open to a similar bug? Shouldn't we be consistent
to avoid copying and pasting some bad pattern? Isn't there something we could do
to avoid more of these bugs?

I have little experience with this code so maybe my questions don't make sense,
so please bear with me.

[reni, 2014/05/22 22:04:38]

This is (was) the only place where the pointer arithmetic on result could be
faulty, because the arithmetic can give wrong length only if the identifier
contains a unicode escape. However, everywhere else the pointer arithmetic is
guarded by "if (!hasEscape)" constructs. It is specific to the at-rules that the
standard enables unicode escapes at some places. This is why we don't have such
a guard around the call to detectAtToken() and why we have to replace the
arithmetic.

[Julien - ping for review, 2014/05/23 10:42:09]

OK, it seems worth a comment here so that people are careful.

         }
         break;