Fix disassembly redirection from stdout into a file.

Fix disassembly redirection from stdout into a file.

Pass \n, \r and \t through OStream without escaping.

BUG=
R=svenpanne@chromium.org

Committed: https://code.google.com/p/v8/source/detail?r=23478

[Vyacheslav Egorov (Google), 2014-08-08 18:21:14]

Sven, could please take a look?

[Vyacheslav Egorov (Google), 2014-08-08 18:23:04]

There might be some reason for escaping those non-printable characters, however
this makes impossible reconstruction of source from the output dumps as escaping
is not reversible unless it will also escape '\'. Which is another possible
solution.

[Sven Panne, 2014-08-25 13:07:09]

On 2014/08/08 18:23:04, Vyacheslav Egorov (Google wrote:
> There might be some reason for escaping those non-printable characters,
however
> this makes impossible reconstruction of source from the output dumps as
escaping
> is not reversible unless it will also escape '\'. Which is another possible
> solution.

I think the overloading for the AsUC16 decorator has no real restrictions on how
it formats its output, so it seems OK to change it. (The rest of the
overloadings mirror what the C++ library does, so we shouldn't change those.)

[Sven Panne, 2014-08-25 13:07:21]

LGTM with a nit.

https://codereview.chromium.org/458533002/diff/1/src/ostreams.cc
File src/ostreams.cc (right):

https://codereview.chromium.org/458533002/diff/1/src/ostreams.cc#newcode169
src/ostreams.cc:169: (c.value == '\r') ||
This indentation looks funny, is "git cl format" happy with that?

[Vyacheslav Egorov (Google), 2014-08-25 15:56:33]

Thanks for the review, Sven!

https://codereview.chromium.org/458533002/diff/1/src/ostreams.cc
File src/ostreams.cc (right):

https://codereview.chromium.org/458533002/diff/1/src/ostreams.cc#newcode169
src/ostreams.cc:169: (c.value == '\r') ||
On 2014/08/25 13:07:20, Sven Panne wrote:
> This indentation looks funny, is "git cl format" happy with that?

The funny indentation is actually the result of applying git cl format. 

I don't like it to be honest. Something is off here.

[Vyacheslav Egorov (Google), 2014-08-25 16:31:14]

Hmm. Can't land this. There is a RegExp test that actually expects this kind of
escaping.

I don't understand how this works without escaping \ though. I will dig and
update this CL.

[Vyacheslav Egorov (Google), 2014-08-25 17:59:56]

Ok, here is another attempt. 

Digging back in history it seems that current AsUC16 behaves pretty much like %k
used to behave. %k was almost exclusively used for by jsregexp printing code
(probably to make output compatible with dot file format and avoid 0 bytes in
char* strings). 

I think %k was (un)intentionally not reversible. It's a testing and debugging
facility only after all so it would be fine with %k%k producing something like
"\\0xa" which impossible to turn back into symbols (is it '\\' and '0' 'x' 'a'
or '\' '\n', nobody knows).

I decided to introduce reversible encoding on the side leaving AsUC16 behave as
it is. After all for reversibility it is enough to guarantee that '\\' is also
escaped as its character code.

Please take another look, Sven!

[Sven Panne, 2014-08-26 06:58:53]

lgtm

[Sven Panne, 2014-08-28 07:31:09]

Committed patchset #2 (id:20001) manually as 23478 (presubmit successful).