[cfe-commits] [PATCH] Using proper file mode for -E

[Aaron Ballman]

On Fri, Sep 23, 2011 at 12:42 PM, Douglas Gregor <dgregor at apple.com> wrote:
> On Sep 18, 2011, at 7:46 AM, Aaron Ballman wrote:
>
>> This is a fix for Bug 6870.
>>
>> On Windows, we really do want CRLFs to remain, otherwise the output
>> ends up looking incredibly bad when piped to a file (even though it
>> looks fine on the command prompt).  For instance:
>>
>> clang.exe -E some_file.cpp > test.txt
>>
>> With Unix line endings, that will produce output which appears all in
>> a single line in some text editors (such as notepad).  Such as:
>>
>> #line 1 "some_file.cpp" #line 1 "some_file.cpp" #line 1 "<built-in>"
>> #line 1 "<built-in>" #line 138 "<built-in>" #line 1 "<command line>"
>> #line 1
>> and so on...
>>
>> But with CRLFs, the output ends up looking fine:
>> #line 1 "some_file.cpp"
>> #line 1 "some_file.cpp"
>> #line 1 "<built-in>"
>> #line 1 "<built-in>"
>> #line 138 "<built-in>"
>> #line 1 "<command line>"
>> #line 1
>
>
> The use of binary mode was intentional, because we didn't want to translate files with just LF's to CRLF's. The ideal behavior would probably be to emit CRLF's consistently if the input file used CRLF, and emit LF's consistently otherwise.

Here's another attempt -- this time I am trying to determine the
original file's line endings so I can match them.  I do this by
looking at the first N bytes of the file to find a CRLF, CR or LF.

I'm uncertain of whether it's worth it to move the line ending check
code into llvm\Support\FileUtilities.h or not.

Thanks for the review!

~Aaron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OptELineEndings.diff
Type: application/octet-stream
Size: 2519 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110923/8e4c9260/attachment.obj>