The following C program:
int main(void)
{
int x = -2147483648;
return (0);
}
Produces the following warning:
temp.c: In function `main':
temp.c:3: warning: decimal constant is so large that it is unsigned
on gcc on Win98 and MVS.
As far as I can tell, that is in fact the maximum negative number on
those
environments and therefore the constant fits into a signed integer and
therefore I shouldn't be getting a warning.
Any ideas? I checked the FAQ but didn't see anything.
Thanks. Paul.
26  3655 
kerravon wrote:
The following C program:
int main(void)
{
int x = -2147483648;
return (0);
}
Produces the following warning:
temp.c: In function `main':
temp.c:3: warning: decimal constant is so large that it is unsigned
on gcc on Win98 and MVS.
As far as I can tell, that is in fact the maximum negative number on
those
environments and therefore the constant fits into a signed integer and
therefore I shouldn't be getting a warning.
`-2147483648` isn't a decimal constant; it's an expression. The decimal
constant in question is `2147483648`, which is one bigger than can be
expressed in a 32-bit signed integer.
--
Compiler 15, OP love Hedgehog
"It took a very long time, much longer than the most generous estimates."
- James White, /Sector General/
On Nov 10, 10:30 pm, Chris Dollin <e...@electrichedgehog.netwrote:
kerravon wrote:
The following C program:
int main(void)
{
int x = -2147483648;
return (0);
}
Produces the following warning:
temp.c: In function `main':
temp.c:3: warning: decimal constant is so large that it is unsigned
on gcc on Win98 and MVS.
As far as I can tell, that is in fact the maximum negative number on
those
environments and therefore the constant fits into a signed integer and
therefore I shouldn't be getting a warning.
`-2147483648` isn't a decimal constant; it's an expression. The decimal
constant in question is `2147483648`, which is one bigger than can be
expressed in a 32-bit signed integer.
I see. So is the solution then to make it -2147483648U ?
I can see from other people's limits.h that they have made it
(-2147483647-1). Why would they do that instead of sticking a U
on the end? Is it because the U on the end will force everything
into unsigned arithmetic?
Thanks. Paul.
kerravon <ke******@w3.towrites:
The following C program:
int main(void)
{
int x = -2147483648;
return (0);
}
Produces the following warning:
temp.c: In function `main':
temp.c:3: warning: decimal constant is so large that it is unsigned
on gcc on Win98 and MVS.
As far as I can tell, that is in fact the maximum negative number on
those environments and therefore the constant fits into a signed
integer and therefore I shouldn't be getting a warning.
Except C has no negative literals. Your initializer is an expression:
the unary negation operator is applied to a constant. That constant,
2147483648, is indeed so large that it is unsigned (in C90). Negating
this large unsigned number provokes, technically, integer overflow.
The best way to at you system limits is with:
#include <limits.h>
There you will find INT_MIN. On my system, its definition is
(-INT_MAX - 1). Can see how this avoids any overflow?
There was a subtle change in C99 -- the number 2147483648 must be
interpreted as having type 'signed long long int'. Both because long
long was introduced but also because the rules about what constants
are taken to be signed and unsigned were changed. Thus in C99 there
is no overflow since the negated long long int does, just, fit into an
int.
Obviously the numbers will be different on systems with other integer
sizes.
--
Ben.
On Sat, 10 Nov 2007 03:08:03 -0800,
kerravon <ke******@w3.towrote:
The following C program:
int main(void)
{
int x = -2147483648;
return (0);
}
Produces the following warning:
temp.c: In function `main':
temp.c:3: warning: decimal constant is so large that it is unsigned
Assuming that you're right and that INT_MIN on your system is indeed
-2147483648 (and INT_MAX 2147483647):
I suspect that gcc sees the constant as two tokens: '-' and 2147483648.
2147483648 is larger than INT_MAX, which is what probably
triggers the warning. Try to see if the warning goes away if you write:
int x = -INT_MAX - 1;
Martien
--
|
Martien Verbruggen | prepBut nI vrbLike adjHungarian! qWhat's
| artThe adjBig nProblem? -- Alec Flett
|
kerravon wrote:
On Nov 10, 10:30 pm, Chris Dollin <e...@electrichedgehog.netwrote:
....
>`-2147483648` isn't a decimal constant; it's an expression. The decimal
constant in question is `2147483648`, which is one bigger than can be
expressed in a 32-bit signed integer.
I see. So is the solution then to make it -2147483648U ?
No, -2147483648U is an expression containing the unary '-' operator
acting on an unsigned integer; the result will therefore also have an
unsigned integer type, and therefore a positive value.
I can see from other people's limits.h that they have made it
(-2147483647-1). Why would they do that instead of sticking a U
on the end? Is it because the U on the end will force everything
into unsigned arithmetic?
Yes, that is the reason. When the mathematical value of INT_MIN is
-2147483648, the C expression (-2147483647-1) is one of the simplest
expressions that has that value.
"Ben Bacarisse" <be********@bsb.me.ukwrote in message
news:87************@bsb.me.uk...
There was a subtle change in C99 -- the number 2147483648 must be
interpreted as having type 'signed long long int'. Both because long
long was introduced but also because the rules about what constants
are taken to be signed and unsigned were changed.
Can you generalize this a bit more?
Every integer constant is taken as a long long in C99?
"Serve Lau" <as**@n.tkwrites:
"Ben Bacarisse" <be********@bsb.me.ukwrote in message
news:87************@bsb.me.uk...
>There was a subtle change in C99 -- the number 2147483648 must be
interpreted as having type 'signed long long int'. Both because long
long was introduced but also because the rules about what constants
are taken to be signed and unsigned were changed.
Can you generalize this a bit more?
Every integer constant is taken as a long long in C99?
No. A decimal constant that has no suffix (u, l, etc) will be taken
to be the first of int, long int, long long int that can represent the
value. The full description of how suffixes and prefixes (denoting
octal and hex constants) affect the resulting type is best described
as in it in the standard -- as a table. Octal and hex constants can
either unsigned or signed and the suffixes impose the obvious
restrictions but the table is the clearest way of seeing it all.
In C90 an unadorned decimal constant has type int, long int or
unsigned long int, whichever is the first to be able to represent the
value. Apart from the fact C90 has no long long types, this is
pretty much the only difference.
--
Ben.
Serve Lau wrote:
"Ben Bacarisse" <be********@bsb.me.ukwrote in message
news:87************@bsb.me.uk...
>There was a subtle change in C99 -- the number 2147483648 must be
interpreted as having type 'signed long long int'. Both because long
long was introduced but also because the rules about what constants
are taken to be signed and unsigned were changed.
Can you generalize this a bit more?
Every integer constant is taken as a long long in C99?
No - what he said is based upon the implied assumption that LONG_MAX is
2147483647. If LONG_MAX 2147483647, then the type of 2147483648 could
be long int. If INT_MAX 2147483647, the type of 2147483648 would be
plain int.
The rules for determining the type of an integer constant are given in
section 6.4.4.1p5 and p6. They depend upon many things. It's unsigned if
a 'U' or a 'u' suffix is applied, and it's at least as big as a long if
an 'L' or 'l' suffix is applied, and it's at least as big as a long long
if an 'LL' or 'll' suffix is used. Decimal constants have an unsigned
type only if explicitly labeled with the 'U' or 'u' suffix, or if they
are too big for long long. In contrast, octal and hexadecimal constants
without that suffix can have either a signed or unsigned type. Within
those constraints, the type of an integer constant is generally the
smallest standard type that is big enough to represent that value,
except that is never a type smaller than 'int'. If none of the standard
types is big enough to hold the specified value, an extended integer
type can be used instead.
kerravon wrote:
>
The following C program:
int main(void) {
int x = -2147483648;
return (0);
}
Produces the following warning:
temp.c: In function `main':
temp.c:3: warning: decimal constant is so large that it is unsigned
on gcc on Win98 and MVS.
As far as I can tell, that is in fact the maximum negative number
on those environments and therefore the constant fits into a signed
integer and therefore I shouldn't be getting a warning.
The expression consists of the positive integer 2147483648 and a
negation. The positive integer doesn't fit. You can form the
value with "-2147483648 - 1" on 32 bit systems. On 16 bit (or 31
bit, etc.) systems you will need to use a long.
Another option is:
int x = INT_MIN;
after #include <limits.h>
--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
CBFalconer wrote:
kerravon wrote:
>The following C program:
int main(void) {
int x = -2147483648;
return (0);
}
Produces the following warning:
temp.c: In function `main':
temp.c:3: warning: decimal constant is so large that it is unsigned
on gcc on Win98 and MVS.
As far as I can tell, that is in fact the maximum negative number
on those environments and therefore the constant fits into a signed
integer and therefore I shouldn't be getting a warning.
The expression consists of the positive integer 2147483648 and a
negation. The positive integer doesn't fit. You can form the
value with "-2147483648 - 1" on 32 bit systems. On 16 bit (or 31
bit, etc.) systems you will need to use a long.
Another option is:
int x = INT_MIN;
after #include <limits.h>
Off-by-one? From my limits.h
#define INT_MAX 2147483647
#define INT_MIN (-2147483647-1)
--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Joe Wright <jo********@comcast.netwrites:
CBFalconer wrote:
>kerravon wrote:
>>The following C program:
int main(void) {
int x = -2147483648;
return (0);
}
Produces the following warning:
temp.c: In function `main':
temp.c:3: warning: decimal constant is so large that it is unsigned
[snip]
>Another option is:
int x = INT_MIN;
after #include <limits.h>
Off-by-one? From my limits.h
#define INT_MAX 2147483647
#define INT_MIN (-2147483647-1)
I don't see an off-by-one error. The OP wanted to initialize x to the
value -2147483648. If INT_MIN is defined as above, then
int x = INT_MIN;
is one correct way to do that.
(Two's-complement representations generally do have an extra negative
value.)
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
James Kuyper <ja*********@verizon.netwrites:
kerravon wrote:
>On Nov 10, 10:30 pm, Chris Dollin <e...@electrichedgehog.netwrote:
...
>>`-2147483648` isn't a decimal constant; it's an expression. The decimal
constant in question is `2147483648`, which is one bigger than can be
expressed in a 32-bit signed integer.
I see. So is the solution then to make it -2147483648U ?
No, -2147483648U is an expression containing the unary '-' operator
acting on an unsigned integer; the result will therefore also have an
unsigned integer type, and therefore a positive value.
I'll assume in the following that:
INT_MIN is -2147483648
INT_MAX is 2147483647
UINT_MAX is 4294967295
The numbers above represent numeric values, not necessarily valid C
expressions.
Specifically, given the above assumtions, -2147483648U will have the
value 2147483648U. Negating an unsigned value is equivalent to
subtracting that value from the maximum value of the type plus one.
(For the same reason, -1U has the value 4294967295U.)
If you use the value 2147483648U to initialize an object of type int,
the value must be converted from unsigned int to int. Since the
numeric value 2147483648 is too be to be stored in an int, the result
is implementation-defined (or, in C99, an implementation-defined
signal might be raised). In other words, don't do this if you care
about the portability of your code.
(On a typical two's-complement implementation, converting 2147483648U
to int yields the int value -2147483648, which is exactly what you
want -- but it's not guaranteed by the language, which is why the
compiler is warning you about it.)
>I can see from other people's limits.h that they have made it
(-2147483647-1). Why would they do that instead of sticking a U
on the end? Is it because the U on the end will force everything
into unsigned arithmetic?
Yes, that is the reason. When the mathematical value of INT_MIN is
-2147483648, the C expression (-2147483647-1) is one of the simplest
expressions that has that value.
Right.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
On Sat, 10 Nov 2007 12:59:08 -0800, Keith Thompson wrote:
Joe Wright <jo********@comcast.netwrites:
>CBFalconer wrote:
>>kerravon wrote:
The following C program:
int main(void) {
int x = -2147483648;
return (0);
}
Produces the following warning:
temp.c: In function `main':
temp.c:3: warning: decimal constant is so large that it is unsigned
[snip]
[un-snip]
>>>
The expression consists of the positive integer 2147483648 and a
negation. The positive integer doesn't fit. You can form the
value with "-2147483648 - 1" on 32 bit systems. On 16 bit (or 31
bit, etc.) systems you will need to use a long.
[end un-snip]
>>
Off-by-one?
I don't see an off-by-one error.
The value can be formed with -2147483647 - 1, not -2147483648 - 1.
"James Kuyper" <ja*********@verizon.netwrote in message
news:aKjZi.2772$CI1.80@trnddc03...
Yes, that is the reason. When the mathematical value of INT_MIN
is -2147483648, the C expression (-2147483647-1) is one of the simplest
expressions that has that value.
Is it not possible to use a hex constant such as 0x80000000? Would that be
treated as a bit-pattern that includes the sign bit?
Bart
"Harald van D)&k" <tr*****@gmail.comwrites:
On Sat, 10 Nov 2007 12:59:08 -0800, Keith Thompson wrote:
>Joe Wright <jo********@comcast.netwrites:
>>CBFalconer wrote:
[snip]
>>>The expression consists of the positive integer 2147483648 and a
negation. The positive integer doesn't fit. You can form the
value with "-2147483648 - 1" on 32 bit systems. On 16 bit (or 31
bit, etc.) systems you will need to use a long.
[end un-snip]
>>>
Off-by-one?
I don't see an off-by-one error.
The value can be formed with -2147483647 - 1, not -2147483648 - 1.
D'oh! You're right; I misread the "-2147483647 - 1"" in CBFalconer's
post as ""-2147483647 - 1".
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
"Bartc" <ba***@freeuk.comwrites:
"James Kuyper" <ja*********@verizon.netwrote in message
news:aKjZi.2772$CI1.80@trnddc03...
>Yes, that is the reason. When the mathematical value of INT_MIN
is -2147483648, the C expression (-2147483647-1) is one of the simplest
expressions that has that value.
Is it not possible to use a hex constant such as 0x80000000? Would that be
treated as a bit-pattern that includes the sign bit?
A hexadecimal constant doesn't specify a bit pattern; it specifies a
*value*, just as a decimal constant does. The rules for determining
the type vary somewhat for decimal vs. hexadecimal (and for C90
vs. C99).
In C99, the type of a hexadecimal constant is the first of:
int
unsigned int
long int
unsigned long int
long long int
unsigned long long int
which can hold the value. For 0x80000000, assuming 32-bit int, the
result is unsigned int, which creates the same conversion problems as
2147483648U or -2147483648U.
In C90, the sequence is the same except for the omission of long long
int and unsigned long long int, which don't affect this case.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson wrote:
Joe Wright <jo********@comcast.netwrites:
>CBFalconer wrote:
>>kerravon wrote:
The following C program:
int main(void) {
int x = -2147483648;
return (0);
}
Produces the following warning:
temp.c: In function `main':
temp.c:3: warning: decimal constant is so large that it is unsigned
[snip]
>>Another option is:
int x = INT_MIN;
after #include <limits.h>
Off-by-one? From my limits.h
#define INT_MAX 2147483647
#define INT_MIN (-2147483647-1)
I don't see an off-by-one error. The OP wanted to initialize x to the
value -2147483648. If INT_MIN is defined as above, then
int x = INT_MIN;
is one correct way to do that.
(Two's-complement representations generally do have an extra negative
value.)
Chuck suggested "-2147483648 - 1" which is 'off-by-one' I'd say.
--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Keith Thompson wrote:
"Harald van D)&k" <tr*****@gmail.comwrites:
>Keith Thompson wrote:
>>Joe Wright <jo********@comcast.netwrites:
CBFalconer wrote:
[snip]
>>>>The expression consists of the positive integer 2147483648 and a
negation. The positive integer doesn't fit. You can form the
value with "-2147483648 - 1" on 32 bit systems. On 16 bit (or 31
bit, etc.) systems you will need to use a long.
>
[end un-snip]
>>>>
Off-by-one?
I don't see an off-by-one error.
The value can be formed with -2147483647 - 1, not -2147483648 - 1.
D'oh! You're right; I misread the "-2147483647 - 1"" in CBFalconer's
post as ""-2147483647 - 1".
One lousy type has generated at least 3, probably more, discussion
messages. 7 != 8. :-)
--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
On Sat, 10 Nov 2007 11:49:47 +0000, Ben Bacarisse
<be********@bsb.me.ukwrote in comp.lang.c:
kerravon <ke******@w3.towrites:
The following C program:
int main(void)
{
int x = -2147483648;
return (0);
}
Produces the following warning:
temp.c: In function `main':
temp.c:3: warning: decimal constant is so large that it is unsigned
on gcc on Win98 and MVS.
As far as I can tell, that is in fact the maximum negative number on
those environments and therefore the constant fits into a signed
integer and therefore I shouldn't be getting a warning.
Except C has no negative literals. Your initializer is an expression:
the unary negation operator is applied to a constant. That constant,
2147483648, is indeed so large that it is unsigned (in C90). Negating
this large unsigned number provokes, technically, integer overflow.
No, arithmetic on unsigned types never overflows. The result of
negating an unsigned integer has a well-defined result, namely
UINT_MAX - value.
If that value is outside the range of a signed int and used to
initialize one, the result is implementation-defined.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
Jack Klein <ja*******@spamcop.netwrites:
The result of negating an unsigned integer has a well-defined
result, namely UINT_MAX - value.
UINT_MAX - value + 1
--
Ben Pfaff http://benpfaff.org
Jack Klein <ja*******@spamcop.netwrites:
On Sat, 10 Nov 2007 11:49:47 +0000, Ben Bacarisse
<be********@bsb.me.ukwrote in comp.lang.c:
>kerravon <ke******@w3.towrites:
The following C program:
int main(void)
{
int x = -2147483648;
return (0);
}
[...]
>>
Except C has no negative literals. Your initializer is an expression:
the unary negation operator is applied to a constant. That constant,
2147483648, is indeed so large that it is unsigned (in C90). Negating
this large unsigned number provokes, technically, integer overflow.
No, arithmetic on unsigned types never overflows. The result of
negating an unsigned integer has a well-defined result, namely
UINT_MAX - value.
If that value is outside the range of a signed int and used to
initialize one, the result is implementation-defined.
Interesting. This is a change from C90 to C99.
In C90, an unsuffixed decimal integer constant's type is the first of
int
unsigned int
long int
unsigned long int
in which it will fit.
In C99, the list is
int
long int
long long int
So in C99, unlike in C90, an unsuffixed decimal integer constant can
never be of an unsigned type.
So if INT_MAX and LONG_MAX are both 2147483647, then the constant
2147483648 is of type unsigned int in C90 and of type long long int in
C99. In C90:
int x = -2147483648;
converts the unsigned int value 2147483648 to int, which yields an
implementation-defined result. But in C99, it converts the long long
int value -2147483648 to type int, which is well defined.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
"James Kuyper" <ja*********@verizon.netwrote in message
news:9clZi.284$Y32.8@trnddc04...
No - what he said is based upon the implied assumption that LONG_MAX is
2147483647. If LONG_MAX 2147483647, then the type of 2147483648 could be
long int. If INT_MAX 2147483647, the type of 2147483648 would be plain
int.
I see, so then LLONG_MIN will probably be defined as follows in C99
#define LLONG_MIN (-LLONG_MAX-1LL)
Ben Pfaff wrote, On 11/11/07 04:34:
Jack Klein <ja*******@spamcop.netwrites:
>The result of negating an unsigned integer has a well-defined
result, namely UINT_MAX - value.
UINT_MAX - value + 1
For operations other than negations (being talked about above),
subtraction and addition repeat until it is in range. UINT_MAX * 5 will
need the repeat ;-)
--
Flash Gordon
Jack Klein <ja*******@spamcop.netwrites:
On Sat, 10 Nov 2007 11:49:47 +0000, Ben Bacarisse
<be********@bsb.me.ukwrote in comp.lang.c:
>kerravon <ke******@w3.towrites:
The following C program:
int main(void)
{
int x = -2147483648;
return (0);
}
Produces the following warning:
temp.c: In function `main':
temp.c:3: warning: decimal constant is so large that it is unsigned
on gcc on Win98 and MVS.
As far as I can tell, that is in fact the maximum negative number on
those environments and therefore the constant fits into a signed
integer and therefore I shouldn't be getting a warning.
Except C has no negative literals. Your initializer is an expression:
the unary negation operator is applied to a constant. That constant,
2147483648, is indeed so large that it is unsigned (in C90). Negating
this large unsigned number provokes, technically, integer overflow.
No, arithmetic on unsigned types never overflows. The result of
negating an unsigned integer has a well-defined result, namely
UINT_MAX - value.
(ITYM UINT_MAX + 1 - value)
Silly of me. Having pointed out that the constant is unsigned I
should been able to follow through. This is an old "gotcha" with C90.
While, to the initiated, it is clear that negated unsigned values are
never negative (they are just ways to write values calculated form
Uxxx_MAX + 1) it is easy to forget that some large integer constants
are also unsigned.
Frequent users of C are not phased by -1U, -2U etc being positive, but
one can be surprised to find two out of -2147483647, -2147483648 and
-2147483649 are positive (in C90). I think C99's position (where all
three of these are negative on the architecture in question) is much
clearer.
PS. I know you know this. I am typing it as way to anchor it for me!
--
Ben.
Serve Lau wrote:
"James Kuyper" <ja*********@verizon.netwrote in message
news:9clZi.284$Y32.8@trnddc04...
>No - what he said is based upon the implied assumption that LONG_MAX is
2147483647. If LONG_MAX 2147483647, then the type of 2147483648 could be
long int. If INT_MAX 2147483647, the type of 2147483648 would be plain
int.
I see, so then LLONG_MIN will probably be defined as follows in C99
#define LLONG_MIN (-LLONG_MAX-1LL)
/* constants used in Solaris */
#define LLONG_MIN (-9223372036854775807LL-1LL)
#define LLONG_MAX 9223372036854775807LL
#define ULLONG_MAX 18446744073709551615ULL
/* gnuc ones */
#define LONG_LONG_MIN LLONG_MIN
#define LONG_LONG_MAX LLONG_MAX
#define ULONG_LONG_MAX ULLONG_MAX
--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
"Bartc" <ba***@freeuk.coma écrit dans le message de news:
Fi*********************@fe2.news.blueyonder.co.uk. ..
>
"James Kuyper" <ja*********@verizon.netwrote in message
news:aKjZi.2772$CI1.80@trnddc03...
>Yes, that is the reason. When the mathematical value of INT_MIN
is -2147483648, the C expression (-2147483647-1) is one of the simplest
expressions that has that value.
Is it not possible to use a hex constant such as 0x80000000? Would that be
treated as a bit-pattern that includes the sign bit?
With INT_MAX == 2147483647 and INT_MIN == (-2147483647-1), 0x80000000 has
type unsigned int. It would behave differently from (-2147483647-1) in
expressions like ``0x80000000 < 0'' that evaluates to 0 instead of
``(-2147483647-1) < 0'' that evaluates to 1. Whether it converts to the
same value when cast to (int) is not even defined by the standard, but in
does so in all common 32 bit architectures.
--
Chqrlie. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: John Bentley |
last post by:
John Bentley:
INTRO
The phrase "decimal number" within a programming context is ambiguous. It could
refer to the decimal datatype or the related but separate concept of a generic
decimal number....
|
by: Günter Zöchbauer |
last post by:
can anyone tell why
is valid
but
produces compiler error:
An attribute argument must be a constant expression, typeof expression or
array creation expression
|
by: Brad |
last post by:
I have a problem in that I need to change a large decimal value into
its hex equivalent. The largest decimal value I need to represent as
hex is 25516777215. The problem here is that this number...
|
by: Paul Sullivan |
last post by:
decimal d;
d = 1.1M
OR
d= (decimal) 1.1
Discussioon
|
by: Kevin Chambers |
last post by:
Hi there--
I'm having a heck of a time trying to create a field of data type decimal.
It seems like, according to the docs, the following two statements should
work just fine:
ALTER TABLE...
|
by: fctk |
last post by:
hello,
i'm trying to compile this small program:
int main(void) {
unsigned long int max;
max = 4000000000;
|
by: sdlt85 |
last post by:
Hi, the program is asking the user for a number ant he base of the
number, then it will convert the number to decimal.
But is running right only with base 2, 3, 4, 5, 6, 7, 8 but if I try
16 it is...
|
by: Lennart Benschop |
last post by:
Python has had the Decimal data type for some time now. The Decimal data
type is ideal for financial calculations. Using this data type would be
more intuitive to computer novices than float as its...
|
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: 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: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
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: 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,...
|
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,...
| |
