Can anyone explain the following behaviour to a relative newbie…
const char cInputFilenameAndPath[] = "W:\\testerfile.bin";
int filesize = 4584;
char * fileinrampointer;
fileinrampointer = (char*) malloc(filesize);
ifstream fsInputFileStream;
fsInputFileStream.open(cInputFilenameAndPath, fstream::in | fstream::binary);
fsInputFileStream.read((char *)(fileinrampointer), filesize);
for(int f=0; f<4; f++)
{
printf("%x\n", *fileinrampointer);
fileinrampointer++;
}
I was expecting the above code to rread the first 4 bytes of the file I just read into memory. In the loop I am just displaying the current byte pointed to by the pointer then incrementing the pointer ready to display the next byte.
When I run the code I get:
37
ffffff94
42
ffffffd2
The values are correct but every other value seems to be padded up to a 64 bit number.
Because I’m asking it to display the value indicated by a ‘char sized’ pointer, I was expecting char size results but every other result comes out as a long long.
If I asign *fileinrampointer to an unsigned __int8 it leaves me with the value I want (without the leading 1s) which solves the problem, but I’m just wondering if anyone can explain what is happening above?
The expression
*fileinrampointeris of typesigned char, and it is being promoted to asigned intwhile being passed to printf. Thus, the sign bit propagates. Later on, you print it out with%xwhich meansunsigned int in hex, which causes you to print all the 1’s (as opposed to correctly interpret them as a part of a 2’s complement signed integer). Also, ffffffd2 is 8 hex digits which means it’s a 32bit signed integer.If you declare
fileinrampointerasunsigned charorunsigned __int8the sign bit doesn’t propagate during promotion. You may as well leave it signed and cast itISO/IEC 9899:1999 6.5.2.2:
This clearly backs up my statement that this is integer promotion, and not printf interpretation.
Also see
ISO/IEC 9899:1999 7.15.1.1
glibc manual A.2.2.4
glibc manual 12.12.4
securecoding.cert.org