unsigned != size_t on a 64-bit build. Theoretically, a CString can have e.g. a 5GB string buffer on a 64-bit platform. There are various errors that would happen in such a case, such as "unsigned CString::length()" truncating the underlying size. Patch forthcoming.
Created attachment 69889 [details] Patch
Comment on attachment 69889 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=69889&action=review > JavaScriptCore/wtf/MD5.cpp:79 > + ASSERT_WITH_MESSAGE(actual == expected, "input:%s[%zu] actual:%s expected:%s", input.data(), input.length(), actual.data(), expected.data()); Does Visual Studio 2005 support this format?
Adding myself to cc list.
Good point. I did grep for '%zu' and got hits in dom/Node.cpp, but it seems like they are behind some heavy-duty define. The safest in-use paradigm seems to be usage of %lu plus a cast to unsigned long (e.g. DRT; WebSocketChannel.cpp; IconDatabase.cpp).
Attachment 69889 [details] did not build on mac: Build output: http://queues.webkit.org/results/4182094
Created attachment 69893 [details] Patch
Comment on attachment 69893 [details] Patch r+ if you fix the export issue for OSX and Windows (-- Sometime people submit the change with the OSX symbol and then get the symbol for windows for the build error on the buildbots).
Thanks -- I'll learn about the magic exports on Mac and Windows tomorrow :)
Created attachment 70000 [details] Patch for EWS try bot
Comment on attachment 70000 [details] Patch for EWS try bot Hmm - using r? to try and spur the bots into action
Created attachment 70038 [details] Patch
Created attachment 70039 [details] Patch
Comment on attachment 70039 [details] Patch Clearing flags on attachment: 70039 Committed r69277: <http://trac.webkit.org/changeset/69277>
All reviewed patches have been landed. Closing bug.