I see quite a mess both in the post and in the answers. With that input file there are no CR nor newline issues for the simple reason that there are no such chars. fgets doesn't apply any conversion, so it reads the chars one by one, included \ then r then \ then n. Then all previous answers are worth reading as what they say is to be kept in mind as a general principle, but everyone is based on CR / NL with text-open files under Windows, which is NOT the case about that file. I made a debugging version of the program included in the post where I added the analysis char by char first of the buffer filled by fgets, then by iteratively use of fgetc. I also included special writings to screen in case some chars are ASCII 13 or 10. Here the result giving that file as the input:
I am a boy\r\n If shown empty line above this, newline was included in buffer fgets buffer analysis: Char in position 0 of buffer: I (ASCII code: 73) Char in position 1 of buffer: (ASCII code: 32) Char in position 2 of buffer: a (ASCII code: 97) Char in position 3 of buffer: m (ASCII code: 109) Char in position 4 of buffer: (ASCII code: 32) Char in position 5 of buffer: a (ASCII code: 97) Char in position 6 of buffer: (ASCII code: 32) Char in position 7 of buffer: b (ASCII code: 98) Char in position 8 of buffer: o (ASCII code: 111) Char in position 9 of buffer: y (ASCII code: 121) Char in position 10 of buffer: \ (ASCII code: 92) Char in position 11 of buffer: r (ASCII code: 114) Char in position 12 of buffer: \ (ASCII code: 92) Char in position 13 of buffer: n (ASCII code: 110) End of buffer (added by fgets) in position 014 (ASCII code: 0) Value of file position indicator: 14 Read again the file by fgetc: Returned char n. 0: I (ASCII code: 73); file pos. ind.: 1 Returned char n. 1: (ASCII code: 32); file pos. ind.: 2 Returned char n. 2: a (ASCII code: 97); file pos. ind.: 3 Returned char n. 3: m (ASCII code: 109); file pos. ind.: 4 Returned char n. 4: (ASCII code: 32); file pos. ind.: 5 Returned char n. 5: a (ASCII code: 97); file pos. ind.: 6 Returned char n. 6: (ASCII code: 32); file pos. ind.: 7 Returned char n. 7: b (ASCII code: 98); file pos. ind.: 8 Returned char n. 8: o (ASCII code: 111); file pos. ind.: 9 Returned char n. 9: y (ASCII code: 121); file pos. ind.: 10 Returned char n. 10: \ (ASCII code: 92); file pos. ind.: 11 Returned char n. 11: r (ASCII code: 114); file pos. ind.: 12 Returned char n. 12: \ (ASCII code: 92); file pos. ind.: 13 Returned char n. 13: n (ASCII code: 110); file pos. ind.: 14
which confirms what I wrote above: no trace of newline nor CR chars.
N.B.: in a further version of the above debugging version, I changed the opening to a binary stream, but, as I expected, with that input file the result is the same, given that the chars it contains don't trigger any issue about the difference between binary and text streams.
However, according to the result expected by the author of the post, maybe he meant another input file, edited e.g. by Notepad with the writing "I am a boy" and, in the end, the press on the Enter key; of course, under Windows. When running my debugging version - sub-version opening as text with the latter file as the input, I got
I am a boy If shown empty line above this, newline was included in buffer fgets buffer analysis: Char in position 0 of buffer: I (ASCII code: 73) Char in position 1 of buffer: (ASCII code: 32) Char in position 2 of buffer: a (ASCII code: 97) Char in position 3 of buffer: m (ASCII code: 109) Char in position 4 of buffer: (ASCII code: 32) Char in position 5 of buffer: a (ASCII code: 97) Char in position 6 of buffer: (ASCII code: 32) Char in position 7 of buffer: b (ASCII code: 98) Char in position 8 of buffer: o (ASCII code: 111) Char in position 9 of buffer: y (ASCII code: 121) Char in position 10 of buffer: newline (ASCII code: 10) End of buffer (added by fgets) in position 011 (ASCII code: 0) Value of file position indicator: 12 Read again the file by fgetc: Returned char n. 0: I (ASCII code: 73); file pos. ind.: 1 Returned char n. 1: (ASCII code: 32); file pos. ind.: 2 Returned char n. 2: a (ASCII code: 97); file pos. ind.: 3 Returned char n. 3: m (ASCII code: 109); file pos. ind.: 4 Returned char n. 4: (ASCII code: 32); file pos. ind.: 5 Returned char n. 5: a (ASCII code: 97); file pos. ind.: 6 Returned char n. 6: (ASCII code: 32); file pos. ind.: 7 Returned char n. 7: b (ASCII code: 98); file pos. ind.: 8 Returned char n. 8: o (ASCII code: 111); file pos. ind.: 9 Returned char n. 9: y (ASCII code: 121); file pos. ind.: 10 Returned char n. 10: newline (ASCII code: 10); file pos. ind.: 12
Note that the screen shows now "I am a boy" followed by a new, empty line, corresponding to CR+LF added by pressing the Enter key. In the end of the buffer, fgets has put the NULL char to properly terminate the string and, since the file was opened as a text stream, CR+LF are converted into one only ASCII 10 char, also represented as '\n'. Then, the result reported in the post as the expected one
I am a boy\n\0
is correct under the hypotesis the author a different file from what he included.
As a final note, if I run the debugging version - sub-version opening as binary with the same second input file, both the buffer filled by fgets and the sequence of chars returned by fgetc include the CR char, as the opening as binary takes everything as bytes not doing any CR+LF to LF conversion at all.