Hello,
does the expression
(0x41u*0x201)&0x7FFF
yield the well defined value 0x0241, or is the behaviour undefined?
In other words: what's the type of the product on an unsigned by an
int, and does the use of constants make a change ?
Thanks for helping me fully understand typedness of expressions.
François Grieu
16  2862 
"Francois Grieu" <fg****@gmail.comwrote in
>does the expression
(0x41u*0x201)&0x7FFF
yield the well defined value 0x0241, or is the behaviour undefined?
>In other words: what's the type of the product on an unsigned by an
int, and does the use of constants make a change ?
>Thanks for helping me fully understand typedness of expressions.
Bare integer are of type int.
Normally an int has at least 32 bits, so the code is fine.
If int should be 16 bits, you get an overflow. If the int is signed, this is
undefined behaviour. In practise any non-perverse compiler would give you a
compile time diagnostic because the expression is a constant. For exactly
how a perverse compiler would act you can look at the dots and tittles of
the standard.
However your integers are unsigned - hex is by default. So the overflow is
well defiend and has to be a wrapround.
In article <DM******************************@bt.com>,
"Malcolm McLean" <re*******@btinternet.comwrote:
"Francois Grieu" <fg****@gmail.comwrote
>does the expression
(0x41u*0x201)&0x7FFF
yield the well defined value 0x0241, or is the behaviour undefined?
>In other words: what's the type of the product on an unsigned by an
int, and does the use of constants make a change ?
>Thanks for helping me fully understand typedness of expressions.
Normally an int has at least 32 bits, so the code is fine.
In this group, normality is MAXINT >=32767
If int should be 16 bits, you get an overflow. If the int is signed, this is
undefined behaviour. In practise any non-perverse compiler would give you a
compile time diagnostic because the expression is a constant. For exactly
how a perverse compiler would act you can look at the dots and tittles of
the standard.
However your integers are unsigned - hex is by default.
That seems incorrect to me. My reading of the standard is that 0x201
is a (signed) int, not an unsigned int.
6.4.4 constant: "the type of an integer constant is the first
of the corresponding list in chich its value can be represented"
Suffix Decimal constant Octal or Hecadecimal constant
none int int
long int unsigned int
long long int long int
unsigned long int
long long int
unsigned long long int
u or U unsigned int unsigned int
unsigned long int unsigned long int
unsigned long long int unsigned long int
unsigned long long int
(..)
I hope I get the type of constants right, but I admit I am allways
confused with the type of expressions, and what can be safely assumed
about expressions that overflow.
François Grieu
"Malcolm McLean" <re*******@btinternet.comwrites:
"Francois Grieu" <fg****@gmail.comwrote in
>>does the expression
(0x41u*0x201)&0x7FFF
yield the well defined value 0x0241, or is the behaviour undefined?
>>In other words: what's the type of the product on an unsigned by an
int, and does the use of constants make a change ?
>>Thanks for helping me fully understand typedness of expressions.
Bare integer are of type int.
If by "bare" you mean integer constants with no 0 or 0x prefix and no
suffix (u/l/ul/lu/ll/ull/llu and their uppercase equivalents) then
they may also be of type long int or long long int if the magnitude of
the constant requires it.
However your integers are unsigned - hex is by default. So the overflow is
well defiend and has to be a wrapround.
No. With a 0 or 0x prefix an un-suffixed integer constant is signed
if it will fit into a signed int (or into a long int or long long
int). The only different caused by the prefix is that it *may* be
taken as being an unsigned int (or the long or long long versions) if
it fits in one.
--
Ben.
"Francois Grieu" <fg****@gmail.comwrites:
does the expression
(0x41u*0x201)&0x7FFF
yield the well defined value 0x0241, or is the behaviour undefined?
I think so. 0x41u is of type unsigned int and 0x201 is of type int.
In other words: what's the type of the product on an unsigned by an
int, and does the use of constants make a change ?
The signed int will be promoted to unsigned before the multiply. Hex
constants (with no suffix) will be takes as the smallest one of:
int
unsigned int
long int
unsigned long int
long long int
unsigned long long int
that can represent the value.
--
Ben.
Malcolm McLean wrote, On 21/01/07 09:58:
"Francois Grieu" <fg****@gmail.comwrote in
>does the expression
(0x41u*0x201)&0x7FFF
yield the well defined value 0x0241, or is the behaviour undefined?
>In other words: what's the type of the product on an unsigned by an
int, and does the use of constants make a change ?
>Thanks for helping me fully understand typedness of expressions.
Bare integer are of type int.
Unless they do not fit in to an int.
Normally an int has at least 32 bits, so the code is fine.
Depends on your definition of "normally". There are more embedded
systems than non-embedded systems (each desktop/notebook contains more
than one embedded system!) and it is quite common for embedded systems
to have 16 or 24 bit ints.
If int should be 16 bits, you get an overflow.
Wrong. Since 0x41u is an unsigned int and 0x201 is a signed int 0x201
will be converted to an unsigned int and no overflow will occur (the
operation is defined as wrapping without invoking overflow). The same
applies to the &.
If the int is signed,
If? int is signed by *definition*.
this is
undefined behaviour. In practise any non-perverse compiler would give you a
compile time diagnostic because the expression is a constant. For exactly
how a perverse compiler would act you can look at the dots and tittles of
the standard.
However your integers are unsigned - hex is by default.
Where in the standard does it say that? I can't find it.
So the overflow is
well defiend and has to be a wrapround.
Well, you reach the correct conclusion although it is for the wrong reasons.
--
Flash Gordon
Francois Grieu wrote:
Hello,
does the expression
(0x41u*0x201)&0x7FFF
yield the well defined value 0x0241, or is the behaviour undefined?
The calculation will yield a well defined value but it may not be
0x0241. It depends on the range of the types involved in the
expression. For unsigned types, the behaviour is based on modulo 2^n.
Thus for large values, the result will wrap-around, but according to
the C standard, this is well defined, even if it may not be what you
want. Use sufficiently large types to ensure no wrap-around. limits.h
contains the necessary range values for the integral types for your C
implementation.
In other words: what's the type of the product on an unsigned by an
int, and does the use of constants make a change ?
Where's an unsigned value multiplied by a signed one? Just use the u or
ul or ull suffix to force a particular type for the constants.
Francois Grieu wrote:
Hello,
does the expression
(0x41u*0x201)&0x7FFF
yield the well defined value 0x0241, or is the behaviour undefined?
In other words: what's the type of the product on an unsigned by an
int,
The first thing that you must understand is that before any
multiplication can take place, the compiler converts both operands to
the same type. The type chosen (for integers) is the first type in the
following list that can represent the value:
int
unsigned int
long
unsigned long
long long
unsigned long long
In this case, the int operand will be converted to an unsigned int, and
the two unsigned int operands will then be multiplied. The same then
happens with the '&' operator.
The same conversion happens with other types as well:
short s = 15;
long l = 20;
long l2 = l * s;
/* s's value is converted to long before
the multiplication takes place
*/
and does the use of constants make a change ?
No.
--
Clark S. Cox III cl*******@gmail.com
In article <12*************@corp.supernews.com>,
"Clark S. Cox III" <cl*******@gmail.comwrote:
Francois Grieu wrote:
does the expression
(0x41u*0x201)&0x7FFF
yield the well defined value 0x0241, or is the behaviour undefined?
In other words: what's the type of the product on an unsigned by an
int,
The first thing that you must understand is that before any
multiplication can take place, the compiler converts both operands to
the same type. The type chosen (for integers) is the first type in the
following list that can represent the value:
Can't get it: what value? First type that can hold any value
that each operand could take given its type ?
int
unsigned int
long
unsigned long
long long
unsigned long long
In this case, the int operand will be converted to an unsigned int,
I'm willing to agree with this conclusion, but can't reach it applyingthe
above rule: int can hold -1, but unsigned int cannot.
Francois Grieu
In article <11**********************@a75g2000cwd.googlegroups .com>,
"santosh" <sa*********@gmail.comwrote:
Francois Grieu wrote:
does the expression
(0x41u*0x201)&0x7FFF
yield the well defined value 0x0241, or is the behaviour undefined?
The calculation will yield a well defined value but it may not
be 0x0241.
How could that be ? If the product is performed using unsigned type
(which I now tend to beleive is the case), the product can overflow,
but the overall value is still precisely defined.
And If the product was evaluated using signed type, it can overflow,
and overflow on signed cause undefined behaviour (e.g. exception),
does not it ?
Where's an unsigned value multiplied by a signed one?
0x41u*0x201. 0x41u is unsigned, 0x201 is signed. At least I'm
relatively confident on this part.
Francois Grieu
In article <11**********************@a75g2000cwd.googlegroups .com>,
"santosh" <sa*********@gmail.comwrote:
Where's an unsigned value multiplied by a signed one?
0x41u is the unsigned value
0x201 is the signed value
The calculation will yield a well defined value but it may
not be 0x0241.
Following an answer I understand, I beleive this is wrong
"Francois Grieu" <fg****@gmail.comwrites:
does the expression
(0x41u*0x201)&0x7FFF
yield the well defined value 0x0241, or is the behaviour undefined?
In other words: what's the type of the product on an unsigned by an
int, and does the use of constants make a change ?
There have been a lot of wrong answers in this thread. I'll try very
hard not to generate another one.
The constant 0x41u is of type unsigned int, because of the 'u' suffix.
(Without the 'u', it would be of type signed int.)
The constant 0x201 is of type (signed) int. A hexadecimal integer
constant's type is the first of:
int
unsigned int
long int
unsigned long int
long long int
unsigned long long int
in which its value can be represented; 0x201 (513) is guaranteed to
fit in an int.
0x41u * 0x201 multiplies an unsigned int by a signed int. When two
operands of differing type are multiplied, the "usual arithmetic
conversions" are first applied. The rules take about a page of text
to describe fully. In this case, the signed int operand is implicitly
converted to type unsigned int.
The result of 0x41u * 0x201 has the value 33345 (0x8241) and the type
unsigned int. Since unsigned int is guaranteed to be able to
represent values in the range 0 to 65535, the result is representable
directly as an unsigned int; no wraparound is necessary. (33345 might
overflow a signed int, but that's not relevant here.)
The constant 0x7FFF (32767) is of type (signed) int, since its value
is always representable in that type. The "usual arithmetic
conversions" are applied to the operands of the unary "&" operator.
The left operand has value 0x8241 and type unsigned int. The right
operand has value 32767 and type signed int, and is implicitly
converted to unsigned int. The result has the value 0x241 (decimal
577), and type unsigned int.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
In article <ln************@nuthaus.mib.org>
Keith Thompson <ks***@mib.orgwrote:
>There have been a lot of wrong answers in this thread. I'll try very
hard not to generate another one.
Indeed :-)
>The constant 0x201 is of type (signed) int. A hexadecimal integer
constant's type is the first of:
int
unsigned int
long int
unsigned long int
long long int
unsigned long long int
in which its value can be represented ...
Note that the rules changed between C89/C90 and C99. Part of the
change is obvious -- C89/C90 did not have "long long" -- but if I
I remember correctly off-hand, some other details changed as well.
One's best bet, in general, is to use suffixes to force the desired
type everywhere. (In the case of the original expression, the single
"U" suffix in 0x41U is sufficient to force the entire sequence of
operations to be done in "unsigned int", as Keith Thompson describes
in the [unquoted] rest of the article.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Chris Torek wrote:
Keith Thompson <ks***@mib.orgwrote:
There have been a lot of wrong answers in this thread. I'll try very
hard not to generate another one.
Indeed :-)
The constant 0x201 is of type (signed) int. A hexadecimal integer
constant's type is the first of:
int
unsigned int
long int
unsigned long int
long long int
unsigned long long int
in which its value can be represented ...
Note that the rules changed between C89/C90 and C99. Part of the
change is obvious -- C89/C90 did not have "long long" -- but if I
I remember correctly off-hand, some other details changed as well.
The change was with respect to unsuffixed decimal constants. In C90,
the list was int, long, unsigned long; in C99 it became int, long, long
long.
Under C99 an unsuffixed decimal constant cannot result in an
unsigned type (except by implementation extension).
[A trap for young players: all constants are positive irrespective of
the
suffix. A leading minus is an unary operator.]
--
Peter
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
0x41u * 0x201 multiplies an unsigned int by a signed int. When two
operands of differing type are multiplied, the "usual arithmetic
conversions" are first applied. The rules take about a page of text
to describe fully. In this case, the signed int operand is implicitly
converted to type unsigned int.
Many thanks for the explanation. I was misinterpreting the standard
on this part. I'm now figuring the sense of the applicable rules,
in section 6.3.1.8: (..when deealing with integer types..)
the integer promotions are performed on both operands. Then the
following rules are applied to the promoted operands:
If both operands have the same type, then no further conversion
is needed.
Otherwise, if both operands have signed integer types or both
have unsigned integer types, the operand with the type of lesser
integer conversion rank is converted to the type of the operand
with greater rank.
- Otherwise, if the operand that has unsigned integer type has
rank greater or equal to the rank of the type of the other
operand, then the operand with signed integer type is converted
to the type of the operand with unsigned integer type.
Otherwise, if the type of the operand with signed integer type
can represent all of the values of the type of the operand with
unsigned integer type, then the operand with unsigned integer
type is converted to the type of the operand with signed integer
type.
Otherwise, both operands are converted to the unsigned integer
type corresponding to the type of the operand with signed
integer type.
When dealing with 0x41u*0x20, we are in the case marked with ->
because of this extract of 6.3.1.1 (..)
the rank of any unsigned integer type shall equal the rank
of the corresponding signed integer tupe, if any.
Francois Grieu
Francois Grieu wrote:
In article <12*************@corp.supernews.com>,
"Clark S. Cox III" <cl*******@gmail.comwrote:
>Francois Grieu wrote:
>>does the expression
(0x41u*0x201)&0x7FFF
yield the well defined value 0x0241, or is the behaviour undefined?
In other words: what's the type of the product on an unsigned by an
int,
The first thing that you must understand is that before any
multiplication can take place, the compiler converts both operands to
the same type. The type chosen (for integers) is the first type in the
following list that can represent the value:
Can't get it: what value? First type that can hold any value
that each operand could take given its type ?
Should be : "...represent the values". That is, the values of the two
operands.
--
Clark S. Cox III cl*******@gmail.com
"Clark S. Cox III" <cl*******@gmail.comwrites:
Francois Grieu wrote:
In article <12*************@corp.supernews.com>,
"Clark S. Cox III" <cl*******@gmail.comwrote:
Francois Grieu wrote:
does the expression
(0x41u*0x201)&0x7FFF
yield the well defined value 0x0241, or is the behaviour undefined?
In other words: what's the type of the product on an unsigned by an
int,
The first thing that you must understand is that before any
multiplication can take place, the compiler converts both operands to
the same type. The type chosen (for integers) is the first type in the
following list that can represent the value:
Can't get it: what value? First type that can hold any value
that each operand could take given its type ?
Should be : "...represent the values". That is, the values of the two
operands.
That's misleading. The type of the result does not depend on the
values of the operands, only on the types of the operands.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: RU |
last post by:
Hi,
I am working on a porting project to port C/C++ application from
unixware C++, AT&T Standard components to g++ with STL on Linux. This
application has been working properly on...
|
by: Stu |
last post by:
I am trying to build the xerces shared library with 2.3.0 version of
their source code on an AIX 5.1 32 bit machine with the following
version of the g++ compiler
/usr/local/bin/g++ -v
Reading...
|
by: Mike |
last post by:
I am having a problem when a field is spaces being undefined. I wasn't
sure if the problem was Excel or Javascript, so I thought I would post
here first.
The users are able to select from a drop...
|
by: Codemutant |
last post by:
**** Post for FREE via your newsreader at post.usenet.com ****
I just cannot find what is undefined in this code.
|
by: Foolster41 |
last post by:
I'm rather new to C++ programing. I'm using the dev-C++ program on a
windows XP OS. I'm trying to compile the code for a multi user dungeon
(MUD) called circle-mud.
When I compile I get the...
|
by: Don Vaillancourt |
last post by:
What's going on with Javascript.
At the beginning there was the "undefined" value which represented an
object which really didn't exist then came the null keyword. But
yesterday I stumbled...
|
by: Chris Beall |
last post by:
If you want your code to be bulletproof, do you have to explicitly check
for the existence of any possibly-undefined variable?
Example: window.outerHeight is defined by some browsers, but not...
|
by: matty |
last post by:
Hi,
I recently got very confused (well that's my life) about the
"undefined" value. I looked in the FAQ and didn't see anything about
it. On...
|
by: Michael Sgier |
last post by:
Hi
i get thousands of messages like below. How shall i resolve that?
Thanks
Mcihael
Release/src/Utility/RawImage.o: In function `CMaskImage::CMaskImage(int,
int, char const*)':...
|
by: VK |
last post by:
(see the post by ASM in the original thread; can be seen at
<http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/3716384d8bfa1b0b>
as an option)
As that is not in relevance to...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
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...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
