| Summary: | DRT should always print a newline after #EOF | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Eric Seidel (no email) <eric> | ||||
| Component: | New Bugs | Assignee: | Eric Seidel (no email) <eric> | ||||
| Status: | RESOLVED INVALID | ||||||
| Severity: | Normal | CC: | abarth, dpranke | ||||
| Priority: | P2 | ||||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 56729 | ||||||
| Attachments: |
|
||||||
|
Description
Eric Seidel (no email)
2011-10-18 15:02:40 PDT
Created attachment 111509 [details]
Patch
Important to let this land through the commit-queue to make sure I didn't screw anything up in my testing. this change looks fine. Note that we don't enforce that the #EOF start at the beginning of the line either (specifically, in the case of audio tests where the main output is binary data, not text). Does it make sense to change that as well? The code seems mixed about whether #EOF is on its own line or not. Since adding a \n before #EOF might add a \n to some test results, I decided to avoid it for now. You're right that it's possible we're silently ignoring some content in ORWT due to lack of requiring #EOF to be on a line by itself. Comment on attachment 111509 [details]
Patch
re-testing ORWT, I'm seeing failure. Checking...
This is invalid. I was just confused. puts always prints a newline after the string. This change caused us to print double-newlines. The opposite change is probably correct to remove the \n from all the places where we currently have "#EOF\n". |