On Sep 23, 2011, at 2:39 PM, Aaron Ballman wrote:
> On Fri, Sep 23, 2011 at 12:42 PM, Douglas Gregor <[email protected]> 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'd like to avoid loading the file just for this purpose. Is it possible to use
the SourceManager to get at the main file's buffer and check there, so that we
just re-use the already-loaded main source file?
- Doug
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
