Bug 66240 - It's hard to tell what the actual result of a failed JS test is in TestWebKitAPI's output
Summary: It's hard to tell what the actual result of a failed JS test is in TestWebKit...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Adam Roben (:aroben)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-15 11:15 PDT by Adam Roben (:aroben)
Modified: 2011-08-15 12:31 PDT (History)
4 users (show)

See Also:


Attachments
Patch (10.39 KB, patch)
2011-08-15 11:16 PDT, Adam Roben (:aroben)
levin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Roben (:aroben) 2011-08-15 11:15:28 PDT
It's hard to tell what the actual result of a failed JS test is in TestWebKitAPI's output
Comment 1 Adam Roben (:aroben) 2011-08-15 11:16:39 PDT
Created attachment 103929 [details]
Patch
Comment 2 David Levin 2011-08-15 11:34:19 PDT
Comment on attachment 103929 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=103929&action=review

> Tools/TestWebKitAPI/JavaScriptTest.cpp:79
> +    OwnArrayPtr<char> buffer = adoptArrayPtr(new char[bufferSize]);

Interestingly JSStringGetMaximumUTF8CStringSize seems incorrectly used in WebKit/Tools/DumpRenderTree/LayoutTestController.cpp where it adds +1 to the output from it but looking at the implementation of that function. the usage here is correct.
Comment 3 Adam Roben (:aroben) 2011-08-15 12:31:16 PDT
Committed r93052: <http://trac.webkit.org/changeset/93052>