Implicit promotion of chars by bitwise operators

[jonathan]

Hello all,
Can someone tell me: do bitwise operators only work on ints and
"above"? I was auditing some code for bad implicit casts, and one that
came up was of the form "char = char ^ char". Apparently the xor
promotes the types to int and then it was getting cast implicitly to
char again for the assignment. This doesn't make a whole lot of sense
to me... Is this just the compiler (g++ 4.3.2)? Or is this the way it
supposed to be in the C++ specification?

--Jonathan

Example:
#include <iostream>

int main(void) {
unsigned char a = 3, b = 2, c;

c = a ^ b; // I sorta get what this one does. But it "shouldn't"
imho
a ^= b; // I really don't have any idea why a promotion is
happening here
std::cout << c << std::endl;
return 0;
}

Output:
g++ -Wconversion test.cpp
test.cpp: In function ‘int main()’:
test.cpp:6: warning: conversion to ‘unsigned char’ from ‘int’ may
alter its value
test.cpp:7: warning: conversion to ‘unsigned char’ from ‘int’ may
alter its value

 

[James Kanze]

Can someone tell me: do bitwise operators only work on ints
and "above"? I was auditing some code for bad implicit casts,
and one that came up was of the form "char = char ^ char".
Apparently the xor promotes the types to int and then it was
getting cast implicitly to char again for the assignment. This
doesn't make a whole lot of sense to me...

It's what the language requires. In practice, many
architectures (including the PDP-11, which was very influencial
in the early days of C, but also most modern architectures)
can't do any operations on anything smaller than an
int---typically, "smaller than an int" only exists in memory,
and modern, Risc architectures only operate on registers.

In practice, it doesn't matter. It never matters with the
bitwise operators, of course; the results are always the same as
if you'd used the original type. And it never matters with
unsigned arithmetic, either, given the way the standard defines
unsigned arithmetic. And if the implementation uses unchecked
2's complement (mostly the case today), it doesn't matter on
signed arithmetic either.

Is this just the compiler (g++ 4.3.2)? Or is this the way it
supposed to be in the C++ specification? Example:
#include <iostream>

int main(void) {
unsigned char a = 3, b = 2, c;

c = a ^ b; // I sorta get what this one does. But it "shouldn't"
imho
a ^= b; // I really don't have any idea why a promotion is
happening here
std::cout << c << std::endl;
return 0;
}

The promotions are happening because the standard requires it.

Output:
g++ -Wconversion test.cpp
test.cpp: In function ‘int main()’:
test.cpp:6: warning: conversion to ‘unsigned char’ from ‘int’ may
alter its value
test.cpp:7: warning: conversion to ‘unsigned char’ from ‘int’ may
alter its value

The warnings are happening because the author of the compiler
was inordinately stupid. Or more likely, someone, somewhere
wanted it, and it was easy to implement, to make him happy---g++
does *not* turn on this warning with -Wall or -Wextra, which is
probably their way of saying that they don't think it should be
used.

In practice, there's no real way you can implement this sort of
checking automatically. Consider something like:

void
f( int a, int b )
{
int c = a + b ;
// ...
}

The initialization of c is more deserving of a warning than your
code, but of course, you won't get it. In the end, the only
solution is serious code review; the documentation of f, for
example either states the restrictions as part of the contract,
and reviews check that the condition is met at the call site
(just as they check all pre-conditions), or it isn't, and the
reviews declare the code in error because of possible overflow.
(But of course, ensuring that code actually works isn't "in"
these days. It's normally enough that it will run without a
core dump, then out the door, for the users to test it.)