NULL or '\o' usage

MK27 · 07-06-2009, 06:53 PM

Quote:

Originally Posted by brewbuck

No it won't. fgets() pays no attention to '\0'. It reads bytes until it either fills the buffer or sees a '\n'

Yes it will, because the string returned will have a '\0' in the middle of it. So if you now apply another string function to that string (notice I wrote "& friends"!), it will only operate on half the string.

So don't keep trying to obfuscate the issue, brewbuck. Once the OP is comfortable with "normative practices", he/she will be free to get kooky and clever. But no gun jumping!

brewbuck · 07-06-2009, 06:59 PM

Quote:

Originally Posted by MK27

Yes it will, because the string returned will have a '\0' in the middle of it. So if you now apply another string function to that string (notice I wrote "& friends"!), it will only operate on half the string.

How is that fgets() fault? fgets() doesn't read strings. It reads lines.

I do not see why giving an accurate description of the behavior of a certain function is "obfuscation."

Adak · 07-06-2009, 08:05 PM

Quote:

Originally Posted by Tigers!

Et al
Thank you for all your replies.
Having a fiddle last night I could get File A to be read provided it was created in the form

Code:

20090220085501237.RPT20090310111500094.RPT20090316112501203.RPT20090507091000206.RPT20090604103500072.RPT

That is, all the desired file names are in a long string. Of course I had to make sure that the no. of characters taken by fgets was correct at 22

Is it possible to be able to get File A to be created in the form

Code:

20090220085501237.RPT
20090310111500094.RPT
20090316112501203.RPT
20090507091000206.RPT
20090604103500072.RPT

and still be able to be read by fgets?
I am still unsure whether '\0' needs to be added by my programme when creating file A and whether I need to add '\n' (new line or carriage return).
Are the '\0' and '\n' considered as part of the characters that fgets must extract or can they be ignored?

Or maybe I just start again?

The program I posted reads the filenames file, using 1 line per filename, just as you said you needed.

'\0' will automatically be added by fgets *IF* the buffer receiving it, has enough room for it. (It should). Same is true for the newline char, if it is present in the line of text.

You may get rid of the newline char very easily, by using the line of code I show in my program - which itCbitC also mentioned.

You have a working example program. Why don't you run it, and study it? You're wasting time asking questions which that program already shows the answer to.

Cactus_Hugger · 07-06-2009, 08:59 PM

Quote:

Originally Posted by Adak

'\0' will automatically be added by fgets *IF* the buffer receiving it, has enough room for it.

Wrong. fgets() always terminates the buffer with a '\0':

Quote:

The fgets() function shall read bytes from stream into the array pointed to by s, until n-1 bytes are read, or a <newline> is read and transferred to s, or an end-of-file condition is encountered. The string is then terminated with a null byte.

brewbuck · 07-06-2009, 09:25 PM

Quote:

Originally Posted by Cactus_Hugger

Wrong. fgets() always terminates the buffer with a '\0':

I forget myself. Probably because strncpy() does behave that way, while fgets() does something sane. Yay for consistency (not)

Adak · 07-06-2009, 09:36 PM

Quote:

Originally Posted by Cactus_Hugger

Wrong. fgets() always terminates the buffer with a '\0':

So you're really saying that there *is* always room for the end of string char in the buffer?

Ahhh!!

Then I'm glad you agree with me.

**laserlight** · 07-07-2009, 12:50 AM

Quote:

Originally Posted by Adak

You may get rid of the newline char very easily, by using the line of code I show in my program - which itCbitC also mentioned.

The problem with the strlen() method is that if the newline is not present, it would set a character that you do want to keep to a null character. To prevent this, you should either check that the character is indeed a newline, or use strchr() instead, e.g.,

Code:

while (fgets(rptline, sizeof(rptline), rptFile))
{
    char *newline = strchr(rptline, '\n');
    if (newline)
    {
        *newline = '\0';
    }

Quote:

Originally Posted by Adak

So you're really saying that there *is* always room for the end of string char in the buffer?

Yes, unless you lie to fgets(), but that is consistent with your point

Adak · 07-07-2009, 03:42 AM

That's a really good point.

On a last line of the file, where the newline may not be present at the end of the line, it could save you from an inaccurate result, as well.

filename.txt (without a newline), could then be processed as this wrong name:

filename.tx

Which would obviously fail.

**Salem** · 07-07-2009, 09:58 AM

Using fgets() to read directly into the destination string is troublesome to begin with. We're arguing about which method is correct for removing the \n on the assumption that it might not be there.

If it isn't there, then the next time around is going to be a broken line as well (most likely, the tail-end of the current long line). In some rare (or not so rare) cases, you might treat this half of a line as being valid data, and attempt to process it.

char buff[BUFSIZ];
Using this buffer is good for reading any text file you would want to edit manually with a text editor.
- read a line using fgets()
- remove the newline if present, perhaps even do some error handling if there isn't one
- validate the buffer (in this case, is it the right length with .txt on the end)
- use the validated string for whatever.
- rinse and repeat

Here's a test!
myprog.exe < myprog.exe
The error checking might grumble a bit, but it shouldn't do anything stupid, and it definitely shouldn't crash.

07-07-2009, 03:42 AM	#23
Adak Registered User Join Date: Sep 2006 Posts: 2,517	That's a really good point. On a last line of the file, where the newline may not be present at the end of the line, it could save you from an inaccurate result, as well. filename.txt (without a newline), could then be processed as this wrong name: filename.tx Which would obviously fail.
Adak is offline

07-07-2009, 09:58 AM	#24
Salem and the hat of vanishing Join Date: Aug 2001 Location: The edge of the known universe Posts: 21,214	Using fgets() to read directly into the destination string is troublesome to begin with. We're arguing about which method is correct for removing the \n on the assumption that it might not be there. If it isn't there, then the next time around is going to be a broken line as well (most likely, the tail-end of the current long line). In some rare (or not so rare) cases, you might treat this half of a line as being valid data, and attempt to process it. char buff[BUFSIZ]; Using this buffer is good for reading any text file you would want to edit manually with a text editor. - read a line using fgets() - remove the newline if present, perhaps even do some error handling if there isn't one - validate the buffer (in this case, is it the right length with .txt on the end) - use the validated string for whatever. - rinse and repeat Here's a test! myprog.exe < myprog.exe The error checking might grumble a bit, but it shouldn't do anything stupid, and it definitely shouldn't crash. __________________ If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut. Up to 8Mb PlusNet broadband from only £5.99 a month!
Salem is offline

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Linked List Not Saving Value as Int	bar338	C Programming	4	05-04-2009 07:53 PM
Help Debugging my AVL tree program.	Nextstopearth	C Programming	2	04-04-2009 01:48 AM
Compiling 3rd party code problem me too	siavoshkc	C Programming	1	09-12-2007 05:55 AM
Linked List of Linked list of linked list : problem with a condtion	gemini_shooter	C Programming	6	03-02-2005 02:45 AM
Contest Results - May 27, 2002	ygfperson	A Brief History of Cprogramming.com	18	06-18-2002 01:27 PM