Hello,

Why does the following add an extra CR in front of the CRLF's

auto outf = new File("out.txt", "w");
outf.write("this\r\nis\r\na\r\ntest");
outf.close;

If I make the file binary
auto outf = new File("out.txt", "wb");

it works as expected.

I am using 2.065 and windows 7

Thanks,
Dave G

On Mon, 02 Jun 2014 10:14:11 -0400, Dave G <dgregory00@gmail.com> wrote:

> Hello,
>
> Why does the following add an extra CR in front of the CRLF's
>
> auto outf = new File("out.txt", "w");
> outf.write("this\r\nis\r\na\r\ntest");
> outf.close;
>
> If I make the file binary
> auto outf = new File("out.txt", "wb");
>
> it works as expected.
>
> I am using 2.065 and windows 7

The bug is in DMC's C runtime, to which Windows DMD defers for file I/O.

Also note, File is a Ref-counted struct. You do not need to 'new' it:

auto outf = File("out.txt", "wb");

-Steve

On Monday, 2 June 2014 at 14:27:45 UTC, Steven Schveighoffer wrote:
> On Mon, 02 Jun 2014 10:14:11 -0400, Dave G <dgregory00@gmail.com> wrote:
>
>> Hello,
>>
>> Why does the following add an extra CR in front of the CRLF's
>>
>> auto outf = new File("out.txt", "w");
>> outf.write("this\r\nis\r\na\r\ntest");
>> outf.close;
>>
>> If I make the file binary
>> auto outf = new File("out.txt", "wb");
>>
>> it works as expected.
>>
>> I am using 2.065 and windows 7
>
> The bug is in DMC's C runtime, to which Windows DMD defers for file I/O.
>
> Also note, File is a Ref-counted struct. You do not need to 'new' it:
>
> auto outf = File("out.txt", "wb");
>
> -Steve

Ok, Thanks Steve. Is that something that is going to be fixed?

On Mon, 02 Jun 2014 10:36:17 -0400, Dave G <dgregory00@gmail.com> wrote:

> On Monday, 2 June 2014 at 14:27:45 UTC, Steven Schveighoffer wrote:
>> On Mon, 02 Jun 2014 10:14:11 -0400, Dave G <dgregory00@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> Why does the following add an extra CR in front of the CRLF's
>>>
>>> auto outf = new File("out.txt", "w");
>>> outf.write("this\r\nis\r\na\r\ntest");
>>> outf.close;
>>>
>>> If I make the file binary
>>> auto outf = new File("out.txt", "wb");
>>>
>>> it works as expected.
>>>
>>> I am using 2.065 and windows 7
>>
>> The bug is in DMC's C runtime, to which Windows DMD defers for file I/O.
>>
>> Also note, File is a Ref-counted struct. You do not need to 'new' it:
>>
>> auto outf = File("out.txt", "wb");
>>
>> -Steve
>
> Ok, Thanks Steve. Is that something that is going to be fixed?

You would have to ask Walter. Probably the best place is to ask on the DMC forums.

See here: http://digitalmars.com/NewsGroup.html

-Steve

>
> You would have to ask Walter. Probably the best place is to ask on the DMC forums.
>
> See here: http://digitalmars.com/NewsGroup.html
>
> -Steve

Will do.  Thanks!

Am Mon, 02 Jun 2014 14:14:11 +0000
schrieb "Dave G" <dgregory00@gmail.com>:

> Hello,
> 
> Why does the following add an extra CR in front of the CRLF's
> 
> auto outf = new File("out.txt", "w");
> outf.write("this\r\nis\r\na\r\ntest");
> outf.close;
> 
> If I make the file binary
> auto outf = new File("out.txt", "wb");
> 
> it works as expected.
> 
> I am using 2.065 and windows 7
> 
> Thanks,
> Dave G

Redirection of D's I/O through the C runtime needs to be killed with fire. It inherits C's flaws like the various vendor specific extensions to the mode string for important flags like inheritance of file handles in child processes.

-- 
Marco

On Tue, 03 Jun 2014 07:34:35 -0400, Marco Leise <Marco.Leise@gmx.de> wrote:

> Am Mon, 02 Jun 2014 14:14:11 +0000
> schrieb "Dave G" <dgregory00@gmail.com>:
>
>> Hello,
>>
>> Why does the following add an extra CR in front of the CRLF's
>>
>> auto outf = new File("out.txt", "w");
>> outf.write("this\r\nis\r\na\r\ntest");
>> outf.close;
>>
>> If I make the file binary
>> auto outf = new File("out.txt", "wb");
>>
>> it works as expected.
>>
>> I am using 2.065 and windows 7
>>
>> Thanks,
>> Dave G
>
> Redirection of D's I/O through the C runtime needs to be killed
> with fire. It inherits C's flaws like the various vendor
> specific extensions to the mode string for important flags like
> inheritance of file handles in child processes.

I'm working on it. There are so many reasons to remove it. Of course, it will still have to be the default.

-Steve