Hello,
I've been trying to clear up a confusion about
integer promotions during expression evaluation.
I've checked the C FAQ and C++ FAQ (they are
different languages, but I was hoping one would
clear up the confusion), as well as googling
groups and the web.
The confusion is that for a binary operator,
where both operands are of integral type.
If either operand is unsigned long, the other
operand is converted to unsigned long. The
confusing thing is that this has a higher
priority than checking for longs. Similarly,
unsigned ints are checked for before ints.
So it is likely that an int is converted to
an unsigned int, or a long is converted to an
unsigned long. I'm getting this from Schildt's
"The Complete Reference C++", 3rd ed.. I
realize his book is not exactly lauded here, but
I also checked an old draft of the c++ standard: http://www.csci.csusb.edu/dick/c++std/cd2/conv.html,
and it says something similar (but not the same).
In item 1 of section 4.5, they also say that if
something can't fit into an int, it is interpretted
as an unsigned int.
Why is it OK to reinterpret a signed integral type as
its unsigned counterpart? If it's a negative number,
then all of a sudden, the reinterpretatio n yields a
large positive number. I'm assuming that the signed
number is modelled as a 2's complement number, even
though it may be implemented differently in hardware.
Likewise, the unsigned is modelled as a straight binary
coded decimal (BCD). Does the sign bit of the 2's
complement number becomes the MSB of the unsigned
number, with all other bits remaining unchanged?
I've TA'd digital electronics before, so I know that
the mechanics of adding a 2'c complement negative
number is the same as adding the BCD interpretation of
those same bits (as was pointed out in one of my google
groups searches). It seems (to me, and perhaps
wrongly) that the rule of converting signed integral
types to their unsigned counterparts is due to lack of
a better way to handle it. Perhaps the reasoning was
that the resulting bits would still be accurate if one
operand was negative while the other was positive.
I was wondering if anyone could confirm or correct my
understanding of this, and maybe offer some insight as
to why this order of promotion is desirable?
Fred
P.S. An interesting thing is that Schildt points out an
exception. If one operand is a long while the other is
an unsigned int whose value can't fit into a long (e.g.
on a platform where both had the same number of bits),
then both operands convert to unsigned longs. Again, the
conversion from a signed integrap type to an unsigned
counterpart.
--
Fred Ma
Dept. of Electronics, Carleton University
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6 9  4950 
In <40************ ***@doe.carleto n.ca> Fred Ma <fm*@doe.carlet on.ca> writes: The confusion is that for a binary operator,
where both operands are of integral type.
If either operand is unsigned long, the other
operand is converted to unsigned long. The
confusing thing is that this has a higher
priority than checking for longs. Similarly,
unsigned ints are checked for before ints.
So it is likely that an int is converted to
an unsigned int, or a long is converted to an
unsigned long.
This is correct.
Why is it OK to reinterpret a signed integral type as
its unsigned counterpart? If it's a negative number,
then all of a sudden, the reinterpretatio n yields a
large positive number.
Consider the alternative: the unsigned might have to converted to signed,
but such a conversion isn't well defined if the value of the unsigned
cannot be represented by the signed. In such cases, the result is
usually a negative value, and this isn't any better than the actual
scenario you have described above.
The moral of the story: the programmer MUST know what he's doing when
combining signed and unsigned operands.
I'm assuming that the signed
number is modelled as a 2's complement number, even
though it may be implemented differently in hardware.
No need for such an assumption: the result of the conversion is well
defined, regardless of the representation of negative values.
Likewise, the unsigned is modelled as a straight binary
coded decimal (BCD).
The standard does not allow this. The unsigned must be using a pure
binary encoding.
Does the sign bit of the 2's
complement number becomes the MSB of the unsigned
number, with all other bits remaining unchanged?
If the signed value is negative, it is added the maximum value that
can be represented by the unsigned type plus one. This is true regardless
of representation, but, if the representation is two's complement, no
operation needs to be actually performed: the bit pattern of the signed
is merely reinterpreted as unsigned.
While this conversion is well defined and yields the same result,
regardless of implementation, converting an unsigned value that cannot
be represented by a signed type yields an implementation-defined result
(or, in C99, may even raise a signal). So, the standard has chosen the
well defined conversion for this case, which is a good thing.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Dan Pop wrote: Why is it OK to reinterpret a signed integral type as
its unsigned counterpart? If it's a negative number,
then all of a sudden, the reinterpretatio n yields a
large positive number.
Consider the alternative: the unsigned might have to converted to signed,
but such a conversion isn't well defined if the value of the unsigned
cannot be represented by the signed. In such cases, the result is
usually a negative value, and this isn't any better than the actual
scenario you have described above.
The moral of the story: the programmer MUST know what he's doing when
combining signed and unsigned operands.
Yes, it certainly seems so. I'm assuming that the signed
number is modelled as a 2's complement number, even
though it may be implemented differently in hardware.
No need for such an assumption: the result of the conversion is well
defined, regardless of the representation of negative values.
I use it as a conceptual aid, though I realize that it may
not reflect actual implementation. Likewise, the unsigned is modelled as a straight binary
coded decimal (BCD).
The standard does not allow this. The unsigned must be using a pure
binary encoding.
Sorry, getting my terminology mixed up. I meant binary encoding. Does the sign bit of the 2's
complement number becomes the MSB of the unsigned
number, with all other bits remaining unchanged?
If the signed value is negative, it is added the maximum value that
can be represented by the unsigned type plus one. This is true regardless
of representation, but, if the representation is two's complement, no
operation needs to be actually performed: the bit pattern of the signed
is merely reinterpreted as unsigned.
While this conversion is well defined and yields the same result,
regardless of implementation, converting an unsigned value that cannot
be represented by a signed type yields an implementation-defined result
(or, in C99, may even raise a signal). So, the standard has chosen the
well defined conversion for this case, which is a good thing.
Yes, and if the standard had defined it the other way (so that
converting unsigned->signed yields a reinterprettati on of the
potentially fictitious 2's complement representation) , then that would
be well defined too. It seems like an arbitrary choice. Thanks
for confirming how it works.
Fred
--
Fred Ma
Dept. of Electronics, Carleton University
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6
In <40************ ***@doe.carleto n.ca> Fred Ma <fm*@doe.carlet on.ca> writes: Dan Pop wrote:
If the signed value is negative, it is added the maximum value that
can be represented by the unsigned type plus one. This is true regardless
of representation, but, if the representation is two's complement, no
operation needs to be actually performed: the bit pattern of the signed
is merely reinterpreted as unsigned.
While this conversion is well defined and yields the same result,
regardless of implementation, converting an unsigned value that cannot
be represented by a signed type yields an implementation-defined result
(or, in C99, may even raise a signal). So, the standard has chosen the
well defined conversion for this case, which is a good thing.
Yes, and if the standard had defined it the other way (so that
converting unsigned->signed yields a reinterprettati on of the
potentially fictitious 2's complement representation) , then that would
be well defined too.
That would not be possible, given that the standard doesn't require
two's complement representation and other allowed representations (one's
complement and sign-magnitude) don't have a range as wide as two's
complement.
It seems like an arbitrary choice.
It's less arbitrary than it seems to you. OTOH, the way integral
promotions (not to be confused with the usual arithmetic conversions)
work is based on an arbitrary and suboptimal choice (value preserving
instead of the more natural signedness preserving).
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Dan Pop wrote:
In <40************ ***@doe.carleto n.ca> Fred Ma <fm*@doe.carlet on.ca> writes:
Dan Pop wrote:
If the signed value is negative, it is added the maximum value that
can be represented by the unsigned type plus one. This is true regardless
of representation, but, if the representation is two's complement, no
operation needs to be actually performed: the bit pattern of the signed
is merely reinterpreted as unsigned.
While this conversion is well defined and yields the same result,
regardless of implementation, converting an unsigned value that cannot
be represented by a signed type yields an implementation-defined result
(or, in C99, may even raise a signal). So, the standard has chosen the
well defined conversion for this case, which is a good thing.
Yes, and if the standard had defined it the other way (so that
converting unsigned->signed yields a reinterprettati on of the
potentially fictitious 2's complement representation) , then that would
be well defined too.
That would not be possible, given that the standard doesn't require
two's complement representation and other allowed representations (one's
complement and sign-magnitude) don't have a range as wide as two's
complement.
Well, as I said, I'm using two's complement more as a pictorial
guide. Couldn't they just as easily define unsigned->signed
conversion as subtraction of the maxium number representable
by the unsigned type? It seems like an arbitrary choice.
It's less arbitrary than it seems to you. OTOH, the way integral
promotions (not to be confused with the usual arithmetic conversions)
work is based on an arbitrary and suboptimal choice (value preserving
instead of the more natural signedness preserving).
Actually, they way they do it seems to make sense to me. There
is no way to avoid losing information, so why bother pretending
to try? Why not just make to operations work properly for a small
anticipatable subset of cases? The cases that they target is
probably motivated simple hardware visualization e.g. if someone
was using C integers to emulate hardware. This is done in DSP
that is eventually meant to be implemented as hardware. OTOH,
trying to preserve information (even signedness) may give a softer
failure, or less gross error, but the argument against that is
similar to the argument of wanting a programming bug to be easy
to find. You want a bug to have clear and overt symptoms. The
more dramatic the error and its outward signs, the better.
Sort of makes sense, eh?
Fred
--
Fred Ma
Dept. of Electronics, Carleton University
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6
In <40************ ***@doe.carleto n.ca> Fred Ma <fm*@doe.carlet on.ca> writes: Dan Pop wrote:
It's less arbitrary than it seems to you. OTOH, the way integral
promotions (not to be confused with the usual arithmetic conversions)
work is based on an arbitrary and suboptimal choice (value preserving
instead of the more natural signedness preserving).
Actually, they way they do it seems to make sense to me. There
is no way to avoid losing information, so why bother pretending
to try?
You don't know what you're talking about : no loss of information is
possible in the integral promotions.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
> >The confusion is that for a binary operator, where both operands are of integral type.
If either operand is unsigned long, the other
operand is converted to unsigned long.
This is correct.
I don't think it's correct for the binary operator ">>", when
the right-hand operand is an unsigned long
(either that, or my compiler is buggy)
The moral of the story: the programmer MUST know what he's doing when
combining signed and unsigned operands.
A subset of the moral: the programmer MUST know what he's doing
when using C.
Dan Pop wrote:
In <40************ ***@doe.carleto n.ca> Fred Ma <fm*@doe.carlet on.ca> writes:
Dan Pop wrote:
It's less arbitrary than it seems to you. OTOH, the way integral
promotions (not to be confused with the usual arithmetic conversions)
work is based on an arbitrary and suboptimal choice (value preserving
instead of the more natural signedness preserving).
Actually, they way they do it seems to make sense to me. There
is no way to avoid losing information, so why bother pretending
to try?
You don't know what you're talking about: no loss of information is
possible in the integral promotions.
Dan
I don't see why you say no information is lost. You basically
lost the original value of the number by adding the maximum
value representable by the unsigned integer. Sure, you can get
it back, but that entails that you keep track of which operands
in an expression were subjected to this reinterprettati on of the
bits. That is extra information you need, which is just another
manifestation of lost information.
Fred
--
Fred Ma
Dept. of Electronics, Carleton University
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6
Old Wolf <ol*****@inspir e.net.nz> spoke thus: The moral of the story: the programmer MUST know what he's doing when
combining signed and unsigned operands.
A subset of the moral: the programmer MUST know what he's doing
when using C.
Sounds like a superset to me.
--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.
On 30 Jan 2004 14:01:30 GMT, Da*****@cern.ch (Dan Pop) wrote: In <40************ ***@doe.carleto n.ca> Fred Ma <fm*@doe.carlet on.ca> writes:
The confusion is that for a binary operator,
where both operands are of integral type.
(Binary arithmetic, comparison or bitwise operator; the "usual
arithmetic conversions" do not apply for shifts and && and || . Or
(noncompound) assignment or comma, which are syntactically binary
although not what people usually think of as binary operations.)
If either operand is unsigned long, the other
operand is converted to unsigned long. The
confusing thing is that this has a higher
priority than checking for longs. Similarly,
unsigned ints are checked for before ints.
So it is likely that an int is converted to
an unsigned int, or a long is converted to an
unsigned long.
This is correct.
Nit: correct for C89, where ulong is the highest type; in C99 only if
the other operand does not have rank higher than ulong.
Otherwise concur.
- David.Thompson1 at worldnet.att.ne t This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Søren Johansen |
last post by:
Hi,
in Large Scale c++ Design, John Lakos suggests that you should avoid the
"unsigned" keyword and use regular ints. Now I know that this book is
considered mostly outdated and I do use namespaces (which he also suggests
avoiding) and other things, but this particular topic has me puzzled.
The problem is that stl has a lot of size_t types that are unsigned and
since I run a no-warning policy, this forces me to do a lot of casting if...
|
by: Rade |
last post by:
Following a discussion on another thread here... I have tried to understand
what is actually standardized in C++ regarding the representing of integers
(signed and unsigned) and their conversions. The reference should be 3.9.1
(Fundamental types), and 4.7 (Integral conversions).
It seems to me that the Standard doesn't specify:
1) The "value representation" of any of these types, except that (3.9.1/3)
"... The range of nonnegative...
|
by: Aire |
last post by:
1. If a function defined as:
void test_function(unsigned int a)
{
}
Is "test_function(-256);" going to cause undefined behavior?
2. What's "a negative signed value wrapping"?
|
by: CBFalconer |
last post by:
Consider:
#include <stdlib.h>
/* An elementary optimizer is expected to remove most code */
/* Return the absolute value */
unsigned long ulabs(long j)
{
if (0 == LONG_MIN + LONG_MAX) {
if (j < 0) return -j;
|
by: Schüle Daniel |
last post by:
Hello Newsgroup,
I was thinking about integer literals and what default types they get
and how they behave when applied to shift operator
assume sizeof(int) == sizeof(unsigend int) = 4
int ii = -1024;
cout << (ii>>1) << endl; // -512
| | |
by: yves |
last post by:
Hello,
I'm trying to check if only the lsb 8 bits of an integer are used.
bool Func(int x)
{
if ((x & 0xFFFFFF00) == 0)
{
return true;
}
|
by: =?iso-8859-2?B?SmFuIFJpbmdvuQ==?= |
last post by:
Hello everybody,
this is my first post to a newsgroup at all.
I would like to get some feedback on one proposal I am thinking about:
--- begin of proposal ---
Proposal to add
signed/unsigned modifier to class declarations
to next revision of C++ programming language
|
by: tcsvikr |
last post by:
unsigned int _I = _N; // _N is of type unsigned int
for (_Grp = false; *_Pg != CHAR_MAX && '\0' < *_Pg
&& *_Pg < _I - _Np; _Grp = true)
//*_Pg is constant char
In the above code we are comparing constant char with unsigned int(*_Pg < _I - _Np). We are getting a warning of 'warning C4018: '<' : signed/unsigned mismatch' when compiled with highest warning level in VC++. Can anyone...
|
by: john |
last post by:
As far as I know there is only the type wchar_t. However my compiler
compiles both "signed wchar_t" and "unsigned wchar_t".
Are there both signed and unsigned wchar_t types?
|
by: Lamefif |
last post by:
how can the computer tell the difference between the two?
i mean a byte is 8 bit can be 1 or 0
11111111 = 255 unsigned byte
10000000 = -128 or 128 ?
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
| | |
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| | |
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| | |
