ferror(file) == 32

Question

Sometimes, when I open the a file like so:

FILE *file = fopen(fname, "wb");
if(!file) printf("Error code: %d\n",ferror(file));

I get a result of 32. What does this mean? Specifically, for eMbedded Visual C++ 4.0

Also, it seems like eVC does not support perror/errno :(

Final Update: it seems like the underlying problem was with a lack of full USB functionality, so file operations on USB Drives were unreliable. My workaround was to sleep in between reads of a certain size (otherwise, future fopens were affected). But, this was disguised by me trying to find the ferror of NULL.

Answer 1

you should try to test what perror says the error message is. Use like this:

perror("fopen");

it will output a message like this:

fopen: <error description here>

I imagine, since you are using ferror when your file object is NULL, that error 32 is just random garbage as another posted mentioned, probably lack of NULL pointer trapping. use errno/perror to get the error that prevented you from opening the file. in fact, it is illegal to pass a NULL pointer to ferror.

EDIT: I find it surprising that both perror and errno aren't supported with that compiler. I recommend that you find the correct error detection functions and use that. ferror certainly isn't it in this case.

EDIT: look into GetLastError() and FormatMessage(), they should be supported. http://msdn.microsoft.com/en-us/library/ms680582(VS.85).aspx also has an example of there usage. Though you will likely need to replace the microsoft "safe string" functions which ordinary C ones. (ex: StringCchPrintf -> _snprintf/sprintf)

A little googling shows that this might work for you. It's not my code, but looks reasonable:

// OS provides a system error string
DWORD dwError = GetLastError();
CString csDescription;
FormatMessage( FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS,
    NULL, dwError, MAKELANGID(LANG_NEUTRAL,SUBLANG_DEFAULT),
    csDescription.GetBuffer(255), nSize, NULL );
csDescription.ReleaseBuffer();

Answer 2

You are using ferror() in a wrong way: it works only on a valid (non-null) file handle. Passing it NULL (in the case fopen() fails) causes UB, which manifests in your case by printing a random value (not trapping on NULL pointer access suggests that the underlying platform does not have memory protection).