signed/unsigned warnings

Discussion in 'C++' started by persres@googlemail.com, Feb 10, 2011.

  1. Guest

    Hi,
    I am using VS 2005.

    The following code generates a warning :

    unsigned int ui = -1;

    The following don't :
    int a = -1;
    unsigned int tempui = a;
    int b = ui;


    Could someone explain please/
    Thanks
    , Feb 10, 2011
    #1
    1. Advertising

  2. Paul Guest

    "" <> wrote in message
    news:...
    > Hi,
    > I am using VS 2005.
    >
    > The following code generates a warning :
    >
    > unsigned int ui = -1;
    >

    Unsigned variables only holds positive integer values.


    > The following don't :
    > int a = -1;
    > unsigned int tempui = a;

    Here there is a conversion from signed to unsigned, as unsigned cannot hold
    a negative value(the value in a). This is a programming error. This would be
    ok if the value of 'a' was positive, so you don't get a warning.

    > int b = ui;

    This is a level 2 error as ui contans an error value already. This would be
    ok if the value in 'ui' was not in the overflow range.
    >
    >
    > Could someone explain please/
    > Thanks
    >

    The moral of the story is don't assign negative integers to unsigned
    variables.
    If you have an integer type that could posibly go negative just use signed.

    Unsigned variables are basically for saving space. Not always very rellevant
    nowadays unless you have a large number of longs when you could've made do
    with unsigned integers and saved 32-bits per variable.

    HTH.
    Paul, Feb 10, 2011
    #2
    1. Advertising

  3. SG Guest

    On 10 Feb., 10:57, perses wrote:
    >
    >   I am using VS 2005.
    >
    > The following code generates a warning :
    >
    > unsigned int ui = -1;
    >
    > The following don't :
    > int a = -1;
    > unsigned int tempui = a;
    > int b = ui;
    >
    > Could someone explain please/


    Since the conversion from some (possibly signed) integer to an
    unsigned integer is well-defined (*), each of the code fragments may
    rely on this behaviour and intentionally use this implicit conversion
    in which case there is no error. Obviously, the Microsoft Compiler
    considers the chance of a programming error in the first example to be
    higher than the chance of error in the second one. But the reason for
    this is beyond me. In general, this kind of implicit conversion might
    be unexpected in which case it would be a programming error. You'll
    probably be able to shut up the compiler by writing
    static_cast<unsigned>(-1) instead to make it explicit that you want
    this conversion.

    (* the resulting value will be congruent to the original modulo
    pow(2,N) where N is the number of value bits in the target type. Note:
    This only applies for conversions where the targe type is *unsigned*.
    When the target type is *signed*, there is no such guarantee. I
    believe it's undefined behaviour. It might be unspecified or
    implementation-defined. Not sure about that without checking the
    standard.)

    Cheers!
    SG
    SG, Feb 10, 2011
    #3
  4. James Kanze Guest

    On Feb 10, 9:57 am, "" <>
    wrote:

    > I am using VS 2005.


    > The following code generates a warning :


    > unsigned int ui = -1;


    A compiler is allowed to warn about anything. In this case,
    turn the warning off, if you can, or ignore it otherwise. It's
    a stupid warning, since the above is a very common idiom.

    --
    James Kanze
    James Kanze, Feb 10, 2011
    #4
  5. Guest

    On Feb 10, 11:57 am, "Paul" <> wrote:
    > "" <> wrote in message
    >
    > news:...> Hi,
    > >  I am using VS 2005.

    >
    > > The following code generates a warning :

    >
    > > unsigned int ui = -1;

    >
    > Unsigned variables only holds positive integer values.
    >
    > > The following don't :
    > > int a = -1;
    > > unsigned int tempui = a;

    >
    > Here there is a conversion from signed to unsigned, as unsigned cannot hold
    > a negative value(the value in a). This is a programming error. This would be
    > ok if the value of 'a' was positive, so you don't get a warning.
    >
    > > int b = ui;

    >
    > This is a level 2 error as ui contans an error value already. This would be
    > ok if the value in 'ui' was not in the overflow range.
    >
    > > Could someone explain please/
    > > Thanks

    >
    > The moral of the story is don't assign negative integers to unsigned
    > variables.
    > If you have an integer type that could posibly go negative just use signed.
    >
    > Unsigned variables are basically for saving space. Not always very rellevant
    > nowadays unless you have a large number of longs when you could've made do
    > with unsigned integers and saved 32-bits per variable.


    This is completely incorrect. Using unsigned to denote length and
    index gives very helpful warnings. unsigned char can be used for
    binary buffers instead of char buffers.

    >
    > HTH.


    Anyways my question was actually why is there no warning while
    assigning a signed to unsigned. I have never noticed this and I guess
    this is upto the compiler as SG said. I still don't understand why
    signed to unsigned is (rather 'is considered') well defined?
    Thanks
    , Feb 10, 2011
    #5
  6. Guest

    On Feb 10, 1:11 pm, James Kanze <> wrote:
    > On Feb 10, 9:57 am, "" <>
    > wrote:
    >
    > > I am using VS 2005.
    > > The following code generates a warning :
    > > unsigned int ui = -1;

    >
    > A compiler is allowed to warn about anything.  In this case,
    > turn the warning off, if you can, or ignore it otherwise.  It's
    > a stupid warning, since the above is a very common idiom.
    >
    > --
    > James Kanze


    Again, please ignore that line. I was just illustating the
    assymetric behaviour of the compiler. Looks like, in some sense,
    signed to unsigned is safer than unsigned to signed. I am not sure
    why.
    The line
    unsigned int tempui = a;
    should generate a warning, I feel.
    , Feb 10, 2011
    #6
  7. Paul Guest

    "" <> wrote in message
    news:...
    On Feb 10, 11:57 am, "Paul" <> wrote:
    > "" <> wrote in message
    >
    > news:...>
    > Hi,
    > > I am using VS 2005.

    >
    > > The following code generates a warning :

    >
    > > unsigned int ui = -1;

    >
    > Unsigned variables only holds positive integer values.
    >
    > > The following don't :
    > > int a = -1;
    > > unsigned int tempui = a;

    >
    > Here there is a conversion from signed to unsigned, as unsigned cannot
    > hold
    > a negative value(the value in a). This is a programming error. This would
    > be
    > ok if the value of 'a' was positive, so you don't get a warning.
    >
    > > int b = ui;

    >
    > This is a level 2 error as ui contans an error value already. This would
    > be
    > ok if the value in 'ui' was not in the overflow range.
    >
    > > Could someone explain please/
    > > Thanks

    >
    > The moral of the story is don't assign negative integers to unsigned
    > variables.
    > If you have an integer type that could posibly go negative just use
    > signed.
    >
    > Unsigned variables are basically for saving space. Not always very
    > rellevant
    > nowadays unless you have a large number of longs when you could've made do
    > with unsigned integers and saved 32-bits per variable.


    -This is completely incorrect.
    Err no it's not.

    -Using unsigned to denote length and
    -index gives very helpful warnings. unsigned char can be used for
    -binary buffers instead of char buffers.

    unsigned variables can be used for whatever you want, If you want to raise
    an argument about pros and cons of each see that other thread.

    >
    > HTH.


    -Anyways my question was actually why is there no warning while
    -assigning a signed to unsigned.
    - have never noticed this and I guess
    -this is upto the compiler as SG said. I still don't understand why
    -signed to unsigned is (rather 'is considered') well defined?

    Perhaps you should look into the different switches for warning levels,
    changing the compiler warning level may suit you better.
    http://msdn.microsoft.com/en-us/library/ms937402.aspx

    HTH.
    Paul, Feb 10, 2011
    #7
  8. Paul Guest

    "" <> wrote in message
    news:...
    On Feb 10, 1:11 pm, James Kanze <> wrote:
    > On Feb 10, 9:57 am, "" <>
    > wrote:
    >
    > > I am using VS 2005.
    > > The following code generates a warning :
    > > unsigned int ui = -1;

    >
    > A compiler is allowed to warn about anything. In this case,
    > turn the warning off, if you can, or ignore it otherwise. It's
    > a stupid warning, since the above is a very common idiom.
    >
    > --
    > James Kanze


    -Again, please ignore that line. I was just illustating the
    -assymetric behaviour of the compiler. Looks like, in some sense,
    -signed to unsigned is safer than unsigned to signed. I am not sure
    -why.
    -The line
    -unsigned int tempui = a;
    -should generate a warning, I feel.


    Why should the ocmpiler examine the value of every variable? The compiler
    isn't concerned with the value of your variables, unless its a pointer where
    the value is an address.
    Paul, Feb 10, 2011
    #8
  9. James Kanze Guest

    On Feb 10, 12:52 pm, SG <> wrote:
    > On 10 Feb., 10:57, perses wrote:
    > > I am using VS 2005.


    > > The following code generates a warning :


    > > unsigned int ui = -1;


    > > The following don't :
    > > int a = -1;
    > > unsigned int tempui = a;
    > > int b = ui;


    > > Could someone explain please/


    > Since the conversion from some (possibly signed) integer to an
    > unsigned integer is well-defined (*), each of the code
    > fragments may rely on this behaviour and intentionally use
    > this implicit conversion in which case there is no error.
    > Obviously, the Microsoft Compiler considers the chance of
    > a programming error in the first example to be higher than the
    > chance of error in the second one. But the reason for this is
    > beyond me.


    In fact, you could almost justify a warning in the second case.
    In the first case, the alternatives are:

    unsigned int ui = UINT_MAX;
    unsigned int ui = std::numeric_limits<unsigned int>::max();
    unsigned int ui = -1;

    The first two require changing the initializer if you change the
    type to, say, unsigned long. The last works correctly for all
    unsigned types.

    If the compiler authors insist on the warning, they should at
    least inhibit it when the initializer is a constant -1; that's
    *the* standard idiom for initializing unsigned values to their
    maximum.

    --
    James Kanze
    James Kanze, Feb 10, 2011
    #9
  10. Paul Guest

    "James Kanze" <> wrote in message
    news:...
    > On Feb 10, 12:52 pm, SG <> wrote:
    >> On 10 Feb., 10:57, perses wrote:
    >> > I am using VS 2005.

    >
    >> > The following code generates a warning :

    >
    >> > unsigned int ui = -1;

    >
    >> > The following don't :
    >> > int a = -1;
    >> > unsigned int tempui = a;
    >> > int b = ui;

    >
    >> > Could someone explain please/

    >
    >> Since the conversion from some (possibly signed) integer to an
    >> unsigned integer is well-defined (*), each of the code
    >> fragments may rely on this behaviour and intentionally use
    >> this implicit conversion in which case there is no error.
    >> Obviously, the Microsoft Compiler considers the chance of
    >> a programming error in the first example to be higher than the
    >> chance of error in the second one. But the reason for this is
    >> beyond me.

    >
    > In fact, you could almost justify a warning in the second case.
    > In the first case, the alternatives are:
    >
    > unsigned int ui = UINT_MAX;
    > unsigned int ui = std::numeric_limits<unsigned int>::max();
    > unsigned int ui = -1;
    >
    > The first two require changing the initializer if you change the
    > type to, say, unsigned long. The last works correctly for all
    > unsigned types.
    >
    > If the compiler authors insist on the warning, they should at
    > least inhibit it when the initializer is a constant -1; that's
    > *the* standard idiom for initializing unsigned values to their
    > maximum.
    >
    > --


    You can't expect the compiler to keep track of the value each variable
    holds, or do you?

    The reason the compiler generates a warning is probably becuase a literal is
    used. The compiler isn't interested in the values your variables hold and
    doesn't check each assignment for overflow, that is the porgrammers job :)
    Paul, Feb 10, 2011
    #10
  11. Guest

    On Feb 10, 3:18 pm, "Paul" <> wrote:
    > "James Kanze" <> wrote in message
    >
    > news:...
    >
    >
    >
    >
    >
    > > On Feb 10, 12:52 pm, SG <> wrote:
    > >> On 10 Feb., 10:57, perses wrote:
    > >> >   I am using VS 2005.

    >
    > >> > The following code generates a warning :

    >
    > >> >   unsigned int ui = -1;

    >
    > >> > The following don't :
    > >> >   int a = -1;
    > >> >   unsigned int tempui = a;
    > >> >   int b = ui;

    >
    > >> > Could someone explain please/

    >
    > >> Since the conversion from some (possibly signed) integer to an
    > >> unsigned integer is well-defined (*), each of the code
    > >> fragments may rely on this behaviour and intentionally use
    > >> this implicit conversion in which case there is no error.
    > >> Obviously, the Microsoft Compiler considers the chance of
    > >> a programming error in the first example to be higher than the
    > >> chance of error in the second one. But the reason for this is
    > >> beyond me.

    >
    > > In fact, you could almost justify a warning in the second case.
    > > In the first case, the alternatives are:

    >
    > >    unsigned int ui = UINT_MAX;
    > >    unsigned int ui = std::numeric_limits<unsigned int>::max();
    > >    unsigned int ui = -1;

    >
    > > The first two require changing the initializer if you change the
    > > type to, say, unsigned long.  The last works correctly for all
    > > unsigned types.

    >
    > > If the compiler authors insist on the warning, they should at
    > > least inhibit it when the initializer is a constant -1; that's
    > > *the* standard idiom for initializing unsigned values to their
    > > maximum.

    >
    > > --

    >
    > You can't expect the compiler to keep track of the value each variable
    > holds, or do you?
    >
    > The reason the compiler generates a warning is probably becuase a literal is
    > used. The compiler isn't interested in the values your variables hold and
    > doesn't check each assignment for overflow, that is the porgrammers job :)- Hide quoted text -
    >
    > - Show quoted text -


    I think I have wasted everyone's time. Sorry.

    If,
    unsigned int ui;

    Then the line
    int i = ui;

    should generate a warning. Do you also feel so? If not, why not?
    , Feb 10, 2011
    #11
  12. <> wrote:
    > Hi,
    > I am using VS 2005.
    >
    > The following code generates a warning :
    >
    > unsigned int ui = -1;
    >
    > The following don't :
    > int a = -1;
    > unsigned int tempui = a;
    > int b = ui;


    Specify enough warning flags in your compiler and it probably will.
    Juha Nieminen, Feb 10, 2011
    #12
  13. Paul Guest

    "" <> wrote in message
    news:...
    On Feb 10, 3:18 pm, "Paul" <> wrote:
    > "James Kanze" <> wrote in message
    >
    > news:...
    >
    >
    >
    >
    >
    > > On Feb 10, 12:52 pm, SG <> wrote:
    > >> On 10 Feb., 10:57, perses wrote:
    > >> > I am using VS 2005.

    >
    > >> > The following code generates a warning :

    >
    > >> > unsigned int ui = -1;

    >
    > >> > The following don't :
    > >> > int a = -1;
    > >> > unsigned int tempui = a;
    > >> > int b = ui;

    >
    > >> > Could someone explain please/

    >
    > >> Since the conversion from some (possibly signed) integer to an
    > >> unsigned integer is well-defined (*), each of the code
    > >> fragments may rely on this behaviour and intentionally use
    > >> this implicit conversion in which case there is no error.
    > >> Obviously, the Microsoft Compiler considers the chance of
    > >> a programming error in the first example to be higher than the
    > >> chance of error in the second one. But the reason for this is
    > >> beyond me.

    >
    > > In fact, you could almost justify a warning in the second case.
    > > In the first case, the alternatives are:

    >
    > > unsigned int ui = UINT_MAX;
    > > unsigned int ui = std::numeric_limits<unsigned int>::max();
    > > unsigned int ui = -1;

    >
    > > The first two require changing the initializer if you change the
    > > type to, say, unsigned long. The last works correctly for all
    > > unsigned types.

    >
    > > If the compiler authors insist on the warning, they should at
    > > least inhibit it when the initializer is a constant -1; that's
    > > *the* standard idiom for initializing unsigned values to their
    > > maximum.

    >
    > > --

    >
    > You can't expect the compiler to keep track of the value each variable
    > holds, or do you?
    >
    > The reason the compiler generates a warning is probably becuase a literal
    > is
    > used. The compiler isn't interested in the values your variables hold and
    > doesn't check each assignment for overflow, that is the porgrammers job
    > :)- Hide quoted text -
    >
    > - Show quoted text -


    -I think I have wasted everyone's time. Sorry.
    No its good to discuss this.

    -If,
    -unsigned int ui;

    -Then the line
    -int i = ui;

    -should generate a warning. Do you also feel so? If not, why not?

    I think you missed the assignment, ui= -1. The compiler can warn about this
    because you are assigning a negative integer literal to a type that does not
    hold negative values.

    The compiler is aware of this becuase you are using a literal. If you assign
    a value from another variable as in:
    int i = ui;
    The comiler doesn't always know what value this varaible will hold. Imagine,
    for example, ui held some user input value. The compiler can't know this
    value and it's not practical for the compiler to keep track of the value in
    each variable.

    James mentioned using
    unsigned int ui = -1;
    As a way to initialise a variable to its max value, but I'd be carefull with
    that as I don't know if this only works on a 2's compliment machine. (which
    most pc's are anyway, but not all). I don't know is this is guaranteed to
    work on all machines but I'm think James might.

    HTH
    Paul, Feb 10, 2011
    #13
  14. James Kanze Guest

    On Feb 10, 6:15 pm, "Paul" <> wrote:
    > "" <> wrote in message


    > -If,
    > -unsigned int ui;


    > -Then the line
    > -int i = ui;


    > -should generate a warning. Do you also feel so? If not, why not?


    > I think you missed the assignment, ui= -1. The compiler can
    > warn about this because you are assigning a negative integer
    > literal to a type that does not hold negative values.


    The compiler can warn about anything. When initializing an
    unsigned type, using -1 to get the maximum value is more or less
    usual practice; the other solutions are too verbose, and require
    repeating the type name.

    > The compiler is aware of this becuase you are using a literal.
    > If you assign a value from another variable as in:
    > int i = ui;
    > The comiler doesn't always know what value this varaible will
    > hold. Imagine, for example, ui held some user input value. The
    > compiler can't know this value and it's not practical for the
    > compiler to keep track of the value in each variable.


    Exactly. So it *might* be an error. I'm against the warning in
    all cases, but it's certainly more justifiable when you don't
    know the value than when you do.

    > James mentioned using
    > unsigned int ui = -1;
    > As a way to initialise a variable to its max value, but I'd be
    > carefull with that as I don't know if this only works on a 2's
    > compliment machine. (which most pc's are anyway, but not all).
    > I don't know is this is guaranteed to work on all machines but
    > I'm think James might.


    I do know that it is guaranteed, yes. Conversion from signed to
    unsigned is guaranteed to be modulo 2^n, where n is the number
    of bits in the unsigned. Conversion from unsigned to signed is
    implementation defined if the value doesn't fit; in C, at least,
    the implementation is specifically allowed to define it to raise
    a signal.

    --
    James Kanze
    James Kanze, Feb 10, 2011
    #14
  15. Guest

    On Feb 10, 7:02 pm, James Kanze <> wrote:
    > On Feb 10, 6:15 pm, "Paul" <> wrote:
    >
    > > "" <> wrote in message
    > > -If,
    > > -unsigned int  ui;
    > > -Then the line
    > > -int i = ui;
    > > -should generate a warning. Do you also feel so? If not, why not?
    > > I think you missed the assignment, ui= -1. The compiler can
    > > warn about this because you are assigning a negative integer
    > > literal to a type that does not hold negative values.

    >
    > The compiler can warn about anything.  When initializing an
    > unsigned type, using -1 to get the maximum value is more or less
    > usual practice; the other solutions are too verbose, and require
    > repeating the type name.
    >
    > > The compiler is aware of this becuase you are using a literal.
    > > If you assign a value from another variable as in:
    > > int i = ui;
    > > The comiler doesn't always know what value this varaible will
    > > hold. Imagine, for example, ui held some user input value. The
    > > compiler can't know this value and it's not practical for the
    > > compiler to keep track of the value in each variable.

    >
    > Exactly.  So it *might* be an error.  I'm against the warning in
    > all cases, but it's certainly more justifiable when you don't
    > know the value than when you do.
    >
    > > James mentioned using
    > > unsigned int ui = -1;
    > > As a way to initialise a variable to its max value, but I'd be
    > > carefull with that as I don't know if this only works on a 2's
    > > compliment machine. (which most pc's are anyway, but not all).
    > > I don't know is this is guaranteed to work on all machines but
    > > I'm think James might.

    >
    > I do know that it is guaranteed, yes.  Conversion from signed to
    > unsigned is guaranteed to be modulo 2^n, where n is the number
    > of bits in the unsigned.  Conversion from unsigned to signed is
    > implementation defined if the value doesn't fit; in C, at least,
    > the implementation is specifically allowed to define it to raise
    > a signal.
    >
    > --
    > James Kanze


    I think I am opening a different thread as people have got stuck to
    the wrong thing.
    , Feb 11, 2011
    #15
  16. SG Guest

    On 11 Feb., 23:43, persres wrote:
    > I think I am opening a different thread as people have got stuck to
    > the wrong thing.


    Your question has already been answered up to a point where any more
    details would only be guesswork about the internals of the specific
    compiler you used and the developers' thought processes. Te recap:
    Whether the code fragments you showed are wrong or not depends on
    whether the code matches the programmer's intentions. These warnings
    just say "There might be something wrong here" but only the programmer
    would be able to tell for sure. For example, there is nothing wrong
    with

    unsigned u = -1;

    if you want to initialize u with the maximum possible unsigned int
    value, that is. Of course, if you don't want this, writing it would be
    an error (Duh!). Obviously, the compiler writers consider the
    probability of such a code fragment to be an error high enough to
    warrent a warning. If you want to know more about their motivation to
    do so, you should ask the developers at Microsoft.
    SG, Feb 12, 2011
    #16
    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. Jeremy Pyle
    Replies:
    3
    Views:
    52,677
    Mike Treseler
    Jun 28, 2003
  2. kyrpa83
    Replies:
    1
    Views:
    621
    kyrpa83
    Oct 17, 2007
  3. Rob1bureau
    Replies:
    1
    Views:
    804
    joris
    Feb 27, 2010
  4. pozz
    Replies:
    12
    Views:
    731
    Tim Rentsch
    Mar 20, 2011
  5. Ted Sung
    Replies:
    1
    Views:
    307
    Sherm Pendley
    Aug 30, 2004
Loading...

Share This Page