It was thus said that the Great Eric J. Korpela once stated:
So here's where I'm missing it. Under
all three fread scenarios, the
compiler doesn't throw a warning...they all compile cleanly. But only the
first works.
Lack of warnings or code don't have anything to do with whether the code
is correct...
Oh, that reminds me, if you can, crank up the warning level on your
compiler if you can, and track down every single one of them. I run my code
through
gcc -Wall -pedantic -ansi
(although if the supplied system headers are messed up, I might drop the
-ansi flag). Also, be aware that a unspecified char declaration
char c;
can cause c to be treated as a signed *or* unsigned quantity, depending
upon the compiler, so the following code *may* not work on some systems:
void foo(void)
{
char c;
char buffer[256];
for (c = 0 ; c < 256 ; c++)
{
buffer[c] = c;
}
}
Internally, C will treat the assignment to buffer[c] as:
*(buffer + c) = c;
And if c is treated as a signed quantity, then once you hit the value 128,
what you get is (effectively):
*(buffer - 128) = -128;
which is *not* what you want. So beware of using chars as indicies.
Call fread with the following parameters:
1. byte value at address (ucMem+roms[i].iROMStart+MEM_ROM) converted into
a pointer to type char.
2. The value 1 (assuming byte is typedefed to "unsigned char")
3. The value stored in roms[i].iROMLen
4. The value stored in pFH.
It's fairly easy to see why the first parameter is wrong... No warning is
issued because the type of the first parameter is correct. Without the
typecast, a warning should be issued.
Actually, it's correct---it's a pointer. The declaration of fread() takes
a void * as the first parameter, and *any* pointer type can be cast into a
void * without problem, no typecast needed.
-spc (Been there, ported the code, have the core file ... )