fgets

[seemant_sun]

"I am a boy\r\n"

if this string is readed through using fgets in an array what will get readed

[ArkM]

All except '\r' and (may be) quotes ;)

Do you really want to study C i/o basics on DaniWeb forum?
Better search for a good C i/o tutorial. There are lots of good links...

[jephthah]

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' character.

try this out for yourself and see. put in mulitple \r characters for a conclusive demonstration. try also varying the "fopen" to use binary mode, either "wb" or "rb". (also note: '\r' is typically translated as <CR> but even this is not guaranteed by the C standard. )

fptr = fopen("filename.dat","w");
    fputs("I am a boy\r\r\r\n",fptr);
    fclose(fptr);

    fptr = fopen("filename.dat","r");
    fgets(buffer,sizeof(buffer),fptr);

    while(buffer[index])
    {
        printf("%02X ",buffer[index]);
        index++;
    }
    printf("\n");
    fclose(fptr);

[Ancient Dragon]

fgets will return everything up to and including the newline. But the problem is, that a newline character's ASCII representation is system dependent.

Not in memory -- its always '\n' regardless of the operating system. Its just the file systems on physical hard drives that are different from one os to another. When working with text files fgets() will work the same on every operating system that supports that function. So the issues with the file systems isn't really relevant to the OPs question.

[jephthah]

> yes it is correct. - Ancient Dragon
(comment to #3)

wait, so you're saying that fgets() doesn't return the '\r' character in a string?

[ArkM]

The new-line character is defined in C, it's '\n'. The fgets standard library function retains a single new-line character from text mode streams only, but...
be careful:

An implementation need not distinguish between text streams and binary streams. In such an implementation, there need be no new-line characters in a text stream nor any limit to the length of a line.

[WaltP]

In other words, test text/binary on your system and write your code accordingly.

And that test is so much faster than posting on a forum and waiting 4 days, 3.5 hours for the only really definitive answer you've received so far.

:icon_wink:

[seemant_sun]

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' character.

try this out for yourself and see. put in mulitple \r characters for a conclusive demonstration. try also varying the "fopen" to use binary mode, either "wb" or "rb". (also note: '\r' is typically translated as <CR> but even this is not guaranteed by the C standard. )

fptr = fopen("filename.dat","w");
    fputs("I am a boy\r\r\r\n",fptr);
    fclose(fptr);

    fptr = fopen("filename.dat","r");
    fgets(buffer,sizeof(buffer),fptr);

    while(buffer[index])
    {
        printf("%02X ",buffer[index]);
        index++;
    }
    printf("\n");
    fclose(fptr);

Thanks a lot for extra Knowledge