On Sun 04 Jun 06, 8:02 AM, Jeffrey J. Nonken <[EMAIL PROTECTED]> said: > > unsigned char c = 255; > signed int i; > signed int j; > > signed int someFunction(char * nativeChar) > { > return(&nativeChar); > } > > > i = someFunction(*c); > j = c; > > > (I'm extremely rusty on my c pointer syntax and don't have a book handy, > I'm trying to pass a pointer to "c" and return "c" converted to signed > integer. I hope I didn't screw that up too badly.) Assume for the > moment the compilers don't complain about the different pointer types. > > Compiler #1 treats native char type as unsigned. > Compiler #2 treats native char type as signed. > > When you switch from compiler #1 to compiler #2: > What happens to the value of i? > What happens to the value of j?
the pointer syntax is a bit mangled, but that's ok. the gods created java for people who can't get their pointer stuff straight. ;-) both i and j will equal 255. the interpretation of a set of bits is independent of the set of bits. when you pass the bit pattern that corresponds to 255 to someFunction(), the bit pattern doesn't change, even though someFunction() takes a char. BTW, on x86, char almost always means "signed char" but this is platform dependent. but this doesn't even matter since the width of a char is the same as the width of a signed char which is the same as the width of an unsigned char. the "value" of i and j is the same "value" as c. the only provisio is how that value is interpreted. since i and j are both signed ints, when you print them with printf() or cout, the pattern will be interpreted as an unsigned int, that is, 255. not -1. to summarize, someFunction() doesn't change the value of c. pete _______________________________________________ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech