943,712 Members | Top Members by Rank

Ad:
  • C Discussion Thread
  • Unsolved
  • Views: 1458
  • C RSS
Jun 7th, 2009
0

fgets

Expand Post »
"I am a boy\r\n"

if this string is readed through using fgets in an array what will get readed
Similar Threads
Reputation Points: 18
Solved Threads: 1
Newbie Poster
seemant_sun is offline Offline
13 posts
since May 2009
Jun 7th, 2009
1

Re: fgets

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...
Last edited by ArkM; Jun 7th, 2009 at 6:15 pm.
Reputation Points: 1234
Solved Threads: 347
Postaholic
ArkM is offline Offline
2,001 posts
since Jul 2008
Jun 11th, 2009
0

Re: fgets

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. )


  1. fptr = fopen("filename.dat","w");
  2. fputs("I am a boy\r\r\r\n",fptr);
  3. fclose(fptr);
  4.  
  5. fptr = fopen("filename.dat","r");
  6. fgets(buffer,sizeof(buffer),fptr);
  7.  
  8. while(buffer[index])
  9. {
  10. printf("%02X ",buffer[index]);
  11. index++;
  12. }
  13. printf("\n");
  14. fclose(fptr);
Last edited by jephthah; Jun 11th, 2009 at 3:24 am.
Reputation Points: 2143
Solved Threads: 178
Posting Maven
jephthah is offline Offline
2,567 posts
since Feb 2008
Jun 11th, 2009
0

Re: fgets

Click to Expand / Collapse  Quote originally posted by jephthah ...
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.
Sponsor
Team Colleague
Featured Poster
Reputation Points: 5608
Solved Threads: 2282
Retired and Enjoying Life
Ancient Dragon is offline Offline
21,950 posts
since Aug 2005
Jun 11th, 2009
0

Re: fgets

Quote ...
> 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?
Reputation Points: 2143
Solved Threads: 178
Posting Maven
jephthah is offline Offline
2,567 posts
since Feb 2008
Jun 11th, 2009
0

Re: fgets

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:
Quote ...
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.
Reputation Points: 1234
Solved Threads: 347
Postaholic
ArkM is offline Offline
2,001 posts
since Jul 2008
Jun 11th, 2009
0

Re: fgets

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.

Moderator
Reputation Points: 3278
Solved Threads: 890
Posting Sage
WaltP is offline Offline
7,718 posts
since May 2006
Jun 12th, 2009
0

Re: fgets

Click to Expand / Collapse  Quote originally posted by 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. )


  1. fptr = fopen("filename.dat","w");
  2. fputs("I am a boy\r\r\r\n",fptr);
  3. fclose(fptr);
  4.  
  5. fptr = fopen("filename.dat","r");
  6. fgets(buffer,sizeof(buffer),fptr);
  7.  
  8. while(buffer[index])
  9. {
  10. printf("%02X ",buffer[index]);
  11. index++;
  12. }
  13. printf("\n");
  14. fclose(fptr);







Thanks a lot for extra Knowledge
Reputation Points: 18
Solved Threads: 1
Newbie Poster
seemant_sun is offline Offline
13 posts
since May 2009

This thread is more than three months old

No one has posted to this discussion for at least three months. Please let old threads die and do not reply to them unless you feel you have something new and valuable to contribute that absolutely must be added to make the discussion complete. Otherwise, please start a new thread in this forum instead.
Message:
Previous Thread in C Forum Timeline: How can i more control rand()
Next Thread in C Forum Timeline: Factorial code error





About Us | Contact Us | Advertise | Acceptable Use Policy
Forum Index | Build Custom RSS Feed


Follow us on Twitter


© 2011 DaniWeb® LLC