the answer to this question is not straightforward at all.
fgets will return everything up to and including the newline. But the problem is, that a newline character's ASCII representation is system dependent.
on *nix environments, the newline character ('\n') is typically represented as a single byte, the <LF> or "linefeed" character, ascii 0x0A. on windows and similar platforms, it is typically a double byte, the <CR> "carriage return" plus the <LF> "linefeed", ascii 0x0D and 0x0A.
However, when you add "fgets()", it becomes more complicated and depends on whether you're reading in text mode or binary mode....
when reading a file that was opened in text mode, "fgets" treats all newline characters as just a single linefeed. therefore, whether the newline character is represented as a single 0x0D, or a double 0x0D 0x0A... fgets pulls in only the 0x0A in either case as its newline. any <CR> component is silently discarded!
this makes "fgets()" problematic for binary files.
try to "fgets" the following stream: "I am a boy\n", you will receive 11 bytes: 0x49 20 61 6d 20 61 20 62 6f 79 0A, even though the newline character may be represented as 0x0D 0x0A in the original stream
when you fgets the folllowing stream: "I am a boy\r\n", you will receive 12 bytes: 0x49 20 61 6d 20 61 20 62 6f 79 0D 0A .. the extra byte, 0x0D, is actually from the '\r' character, and not from the '\n' …