File Reading in C, Random Error

Thank you everybody so far for your input and advice!

Additionally:

After testing and toying further, it seems individual calls to FileReader succeed. But calling FileReader multiple times (these might be separate versions of FileReader) causes the issue to occur.

End Add

Hello,

I have a very unusual problem [please read this fully: it's important] (Code::Blocks compiler, Windows Vista Home) [no replicable code] with the C File Reading functions (fread, fgetc). Now, normally, the File Reading functions load up the data correctly to a self开发者_如何转开发-allocating and self-deallocating string (and it's not the string's issue), but this is where it gets bizarre (and where Quantum Physics fits in):

An error catching statement reports that EOF occurred too early (IE inside the comments section at the start of the text file it's loading). Printing out the string [after it's loaded] reports that indeed, it's too short (24 chars) (but it has enough space to fit it [~400] and no allocation issues). The fgetc loop iterator reports it's terminating at just 24 (the file is roughly 300 chars long) with an EOF: This is where it goes whacky:

Temporarily checking Read->_base reports the entire (~300) chars are loaded - no EOF at 24. Perplexed, [given it's an fgetc loop] I added a printf to display each char [as a %d so I could spot the -1 EOF] at every step so I could see what it was doing, and modified it so it was a single char. It loops fine, reaching the ~300 mark instead of 24 - but freezes up randomly moments later. BUT, when I removed printf, it terminated at 24 again and got caught by the error-catching statement.

Summary: So, basically: I have a bug that is affected by the 'Observer Effect' out of quantum physics: When I try to observe the chars I get from fgetc via printf, the problem (early EOF termination at 24) disappears, but when I stop viewing it, the error-catch statement reports early termination.

The more bizarre thing is, this isn't the first time it's occurred. Fread had a similar problem, and I was unable to figure out why, and replaced it with the fgetc loop.

[Code can't really be supplied as the code base is 5 headers in size].

Snippet:

int X = 0; 
int C = 0; 
int I = 0;

while(Copy.Array[X] != EOF)
{
    //Copy.Array[X] = fgetc(Read);
    C = fgetc(Read);
    Copy.Array[X] = C;
    printf("%d %c\n",C,C); //Remove/add this as necessary
    if(C == EOF){break;}
    X++;
}

Side-Note: Breaking it down into the simplest format does not reproduce the error.

This is the oldest error in the book, kind of.

You can't use a variable of type char to read characters (!), since the EOF constant doesn't fit.

You need:

int C;

Also, the while condition looks scary, you are incrementing X in the loop, then checking the (new) position, is that properly initialized? You don't show how Copy.Array is set up before starting the loop.

I would suggest removing that altogether, it's very strange code.

In fact, I don't understand why you loop reading single characters at all, why not just use fread() to read as much as you need?

Firstly, unwind's answer is a valid point although I'm not sure whether it explains the issues you are seeing.

Secondly,

printf("%d %c\n",C,C); //Remove/add this as necessary

might be a problem. The %d and %c format specifiers expect an int to be the parameter, you are only passing a char. Depending on your compiler, this might mean that they are too small.

This is what I think the problem is:

How are you allocating Copy.Array? Are you making sure all its elements are zeroed before you start? If you malloc it (malloc just leaves whatever garbage was in the memory it returns) and an element just happens to contain 0xFF, your loop will exit prematurely because your while condition tests Copy.Array[X] before you have placed a character in that location.

This is one of the few cases where I allow myself to put an assignment in a condition because the pattern

int c;
while ((c = fgetc(fileStream)) != EOF)
{
    doSomethingWithC(c);
}

is really common

Edit

Just read your "Additionally" comment. I think it is highly likely you are overrunning your output buffer. I think you should change your code to something like:

    int X = 0; int C = 0; int I = 0;
    while(X < arraySize && (C = fgetc(Read)) != EOF)
    {
        Copy.Array[X] = C;
        printf("%d %c\n", (int)C, (int)C);
        X++;
    }
    printf("\n");

Note that I am assuming that you have a variable called arraySize that is set to the number of characters you can write to the array without overrunning it. Note also, I am not writing the EOF to your array.

You probably have some heap corruption going on. Without seeing code it's impossible to say.

Not sure if this is your error but this code:

C = fgetc(Read);
Copy.Array[X] = C;
if(C == EOF){break;}

Means you are adding the EOF value into your array - I'm pretty sure you don't want to do that, especially as your array is presumably char and EOF is int, so you'll actually end up with some other value in there (which could mess up later loops etc).

Instead I suggest you change the order so C is only put in the array once you know it is not EOF:

C = fgetc(Read);
if(C == EOF){break;}
Copy.Array[X] = C;

Whilst this isn't what I'd call a 'complete' answer (as the bug remains), this does solve the 'observer effect' element: I found, for some reason, printf was somehow 'fixing' the code, and using std::cout seemed to (well, I can't say 'fix' the problem) prevent the observer effect happening. That is to say, use std::cout instead of printf (as printf is the origin of the observer effect).

It seems to me that printf does something in memory on a lower level that seems to partially correct what does indeed seem to be a memory allocation error.