Re: Implicit promotion of chars by bitwise operators
On Apr 11, 4:57 pm, jonat...@sliid.org wrote:
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 i=
s
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 =91int main()':
test.cpp:6: warning: conversion to =91unsigned char' from =91int' may
alter its value
test.cpp:7: warning: conversion to =91unsigned char' from =91int' 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.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34