signed/unsigned warnings

P

persres

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
 
P

Paul

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.
 
S

SG

  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
 
P

persres

Unsigned variables only holds positive integer values.


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.


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.


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.

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
 
P

persres

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.

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.
 
P

Paul

Hi,



Unsigned variables only holds positive integer values.


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.


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.


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.

-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.
 
P

Paul

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.

-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.
 
J

James Kanze

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.
 
P

Paul

James Kanze said:
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 :)
 
P

persres

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?
 
J

Juha Nieminen

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.
 
P

Paul

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
 
J

James Kanze

"(e-mail address removed)" <[email protected]> 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.
 
P

persres

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.


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.


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.

I think I am opening a different thread as people have got stuck to
the wrong thing.
 
S

SG

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.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,898
Latest member
BlairH7607

Latest Threads

Top