[vox-tech] C - passing chars and pointer to chars

[Peter Jay Salzman]

On Sun 04 Jun 06,  8:02 AM, Jeffrey J. Nonken <jjn_lugod at nonken.net> 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