| | |
fgets
Please support our C advertiser: Programming Forums - DaniWeb Sister Site
![]() |
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. )
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. )
c Syntax (Toggle Plain Text)
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);
Last edited by jephthah; Jun 11th, 2009 at 3:24 am.
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.
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:
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.
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.
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.
The 3 Laws of the Procrastination Society:
1) Never do today that which can be put off until tomorrow
2) Tomorrow never comes
1) Never do today that which can be put off until tomorrow
2) Tomorrow never comes
•
•
Join Date: May 2009
Posts: 13
Reputation:
Solved Threads: 1
•
•
•
•
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. )
c Syntax (Toggle Plain Text)
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
![]() |
Similar Threads
- am i using fgets correctly? (Cprog) (C)
- miserable fgets and a 2d array (C)
- Fread + Ssl (PHP)
- piglatin program with fgets, strtok, and strlen (C)
Other Threads in the C Forum
- Previous Thread: How can i more control rand()
- Next Thread: Factorial code error
Views: 604 | Replies: 7
| Thread Tools | Search this Thread |
Tag cloud for C
#include * append array arrays asterisks binarysearch calculate changingto char character cm command copyimagefile creafecopyofanytypeoffileinc database directory dynamic execv feet fgets file floatingpointvalidation fork forloop framework function functions getlogicaldrivestrin givemetehcodez grade graphics gtkwinlinux hacking histogram homework ide include incrementoperators input intmain() iso kernel keyboard kilometer km lazy license linked linkedlist linux list lists looping loopinsideloop. lowest matrix microsoft mqqueue number oddnumber odf openwebfoundation overwrite owf pause pdf performance pointer posix probleminc process program programming radix recursion recv recvblocked research reversing scripting segmentationfault sequential single socket socketprogramming spoonfeeding standard string student systemcall testing threads turboc unix urboc user variable whythiscodecausesegmentationfault windowsapi







