C escape \n puts carriage return line feed - by Indinfer

Status : 

  By Design<br /><br />
		The product team believes this item works according to its intended design.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


1
0
Sign in
to vote
ID 651563 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 3/15/2011 9:54:30 AM
Access Restriction Public

Description

I thought that in C-Language the escape sequence '\r' is for carriage return and '\n' is for line feed. However, '\n' inserts a carriage return followed by a line feed. '\r' inserts just a carriage return.

Is there a change in standard C? Or is there a configuration setting that controls this?

Sign in to post a comment.
Posted by James [MSFT] on 1/3/2013 at 4:28 PM
As noted in the comments below, this behavior is by-design: text streams map between the logical newline \n and the platform newline sequence, which on Windows is \r\n.
Posted by Indinfer on 6/12/2012 at 10:33 AM
I recommend this Bug Report should be closed as "by design" to specifications of Standard C. Files opened in text mode will convert new_line sequences depending on the operating system. Files opened in binary mode will not change anything.

So in text mode for Windows, reading from a file a new_line sequence of \r\n will result in just \n in the buffer. Writing \n will result in \r\n in the file.

Sorry for my own confusion. Thank you for being gentle.

Sources:
http://www.geekinterview.com/question_details/3366
http://en.wikipedia.org/wiki/Newline
http://jbssupport.blogspot.com/2011/03/c-language-file-handling-part-2.html

Excerpt from last source:
The handling of newlines: In text mode, a newline character is converted into the carriage return – linefeed combination before being written to the disk. Likewise, the carriage return – linefeed combination on the disk is converted back into a newline when a C program reads the file. But, if a file is opened in binary mode, as opposed to text mode, these conversions will not take place. As a result, a character count program, where the file is opened in text mode, shows less number of characters than if the file would have been opened in binary mode. The binary mode value is exactly same as that reported by the DIR command.
Posted by Microsoft on 3/16/2011 at 11:03 PM
Thanks again for your quick response. We are routing this issue to the appropriate group within the Visual Studio Product Team for triage and resolution.These specialized experts will follow-up with your issue.
Posted by Indinfer on 3/16/2011 at 9:33 AM
I just attached a zipped project: crlf.zip. I was able to reproduce the phenominon using this code.
Posted by Microsoft on 3/16/2011 at 2:03 AM
Thank you for reporting this issue.
Could you please attach a demo project and some creenshots to help us investigate this issue?
Posted by Indinfer on 3/15/2011 at 3:45 PM
I think about this further, maybe the \n injecting \r\n is by design. I would suppose that this behavior would make C code copied from other operating systems such as Unix work without changing from \n to \r\n.

On the other hand, see this website says about Standard C:
https://connect.microsoft.com/VisualStudio/feedback/details/651563/c-escape-n-puts-carriage-return-line-feed#tabs

"n --New line 010 Takes the cursor to the beginning of the next lin"

This is not so clear because to go down one line you would use 010. To go down one line and to the beginning of the next line you would use 13 10, i.e. 0x0D 0x0A, i.e. \r\n.

Posted by Microsoft on 3/15/2011 at 10:14 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Posted by Indinfer on 3/15/2011 at 10:05 AM
This code gives exactly the same results:

#include <stdio.h>
int main()
{
    FILE *fp = fopen("Slash_N_Test.txt", "w");
    char n = 0x0A;
    fputc(n, fp);
    fclose(fp);
}

The code assigns the specific value 0x0A. Therefore, this is not a workaround.
Posted by Indinfer on 3/15/2011 at 9:58 AM
This code gives exactly the same results:

#include <stdio.h>
int main()
{
    FILE *fp = fopen("Slash_N_Test.txt", "w");
    fputc('\x0A', fp);
    fclose(fp);
}


The code uses '\x0A' instead of '\r\. Therefore, this is not a workaround.