Implicit promotion of chars by bitwise operators

Discussion in 'C++' started by jonathan@sliid.org, Apr 11, 2009.

  1. Guest

    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
     
    , Apr 11, 2009
    #1
    1. Advertising

  2. James Kanze Guest

    On Apr 11, 4:57 pm, 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 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.)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Apr 12, 2009
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    1
    Views:
    577
    christian.bau
    Jan 15, 2007
  2. swansnow

    operators and type promotion

    swansnow, Dec 12, 2007, in forum: C Programming
    Replies:
    4
    Views:
    332
    swansnow
    Dec 12, 2007
  3. Alf P. Steinbach

    Re: Implicit Promotion of data types

    Alf P. Steinbach, Feb 20, 2010, in forum: C++
    Replies:
    1
    Views:
    669
    Alf P. Steinbach
    Feb 21, 2010
  4. red floyd

    Re: implicit promotion

    red floyd, May 30, 2011, in forum: C++
    Replies:
    8
    Views:
    290
    Öö Tiib
    May 30, 2011
  5. Andrew Cooper

    Implicit integer promotion

    Andrew Cooper, Nov 29, 2013, in forum: C Programming
    Replies:
    18
    Views:
    243
    David Brown
    Dec 22, 2013
Loading...

Share This Page