tags:

views:

223

answers:

2

Basically i am having problems with my code - this is homework so would rather not post it in here for obvious reasons. If it becomes truely important for me to do so then i will have to as i am so stuck.

i am reading 2 text files and it also has a seperator , these values come from the command line, just assume that the seperator in this case is xx

File a
a
b
c


File b
d
e

Output should be
axxd
bxxe
cxx

the problem is that my code just doesnt do the last line correctly

i get an output of

axxd
bxxe

I hope you guys can gather what i am doing wrong without me posting all my code, but my logic works on this principle;

while not at the end of the file for files a and b
    get a line using fgets from a
    create a charachter pointer and set it to the first occurance of \n in the line using strchr
    if the pointer isn't null
        set the pointers value to be the end of line

get the line from b as above
and now write the line from a, the seperator and the line from b to file

Thanks for reading

A: 

Maybe you don't print a newline after printing the last line? Then it may not display on your screen at all. Notice that fgets only puts a newline in your buffer if the original line had one and the last line of a file might not.

Tronic
+4  A: 

This is your first logic problem: while(!feof(a) && !feof(b))

This means that if either file has reached the end then you stop processing, even if there are more lines in the other file.

Charles Bailey
thanks, that gives me soemthign to work off of, however the first means you have found more :S !!
loz
Good old EOF flag. They should put in the documentation "NEVER USE THIS FUNCTION FOR TESTING WHETHER YOU CAN READ MORE", then maybe people would stay away from it.
Tronic
Well, if you just change the while condition and leave the code as it stands you will be attempting to call `fgets` on streams that are potentially at `EOF`. You need to check the return value of `fgets` to make sure that you don't treat old buffer contents as newly read data.
Charles Bailey
logically end of file would suggest there was nothing else left to read :D
loz
The EOF flag is only guaranteed to be set _after_ a failed read. This is why `feof` is considered a code smell. In almost all cases code is much more robust if the result of the particular read function that is tested. In many instances of code that use `feof`, the function isn't called at the correct point in the code and often there is no corresponding `ferror` check.
Charles Bailey
Strange enough, it can also get set after a successful read that simply happens to peek past the end.
Tronic
@Tronic: Yes, on many platforms this happens for things like `fscanf` where it might be reading, say, digits for a number. It hits the end, sets `EOF` but it still read a good number. `feof` doesn't tell you whether it worked; you need to check the return value of `fscanf`. I didn't emphasise all the reasons that `feof` is usually not the right function in my last comment.
Charles Bailey