RE: Is this OK in C++ and C?
Joe Pfeiffer :
int main()
{
const unsigned int n = -5;
cout The variable n is: n endl;
return 0;
}
Results:
$ g++ -Wall -W prog.cpp -o prog
$ ./prog
The variable n is: 4294967291
This is expected behavior, but not defined by the standard because the
result is not portable. That is, a rollover value will occur, but it
could vary depending on the width of an int, and possibly by the
binary representation. As far as I know all systems that Debian with
gcc runs on are two's complement, but still...
I believe it is indeed defined behavior.
6.3.1.3 Signed and unsigned integers
1 When a value with integer type is converted to another integer type
other
than _Bool, if
the value can be represented by the new type, it is unchanged.
2 Otherwise, if the new type is unsigned, the value is converted by
repeatedly adding or
subtracting one more than the maximum value that can be represented in
the new type
until the value is in the range of the new type.49)
Yes, defined conversion, but not a defined *exact* result; that is, the
result is system dependent.
So, yeah.
This kind of type shenanigan is allowed in C/C++ because of silent
standard conversions.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/01a301cde8cf$eb01f220$c105d660$@allums.com
RE: Is this OK in C++ and C?
From: Mark Allums [mailto:m...@allums.com]
int main()
{
const unsigned int n = -5;
cout The variable n is: n endl;
return 0;
}
Results:
$ g++ -Wall -W prog.cpp -o prog
$ ./prog
The variable n is: 4294967291
This is expected behavior, but not defined by the standard because the
result is not portable. That is, a rollover value will occur,
Joe Pfeiffer :
I believe it is indeed defined behavior.
6.3.1.3 Signed and unsigned integers
1 When a value with integer type is converted to another integer type
other than _Bool, if
the value can be represented by the new type, it is unchanged.
2 Otherwise, if the new type is unsigned, the value is converted by
repeatedly adding or
subtracting one more than the maximum value that can be represented
in the new type until the value is in the range of the new type.49)
Me:
Yes, defined conversion, but not a defined *exact* result; that is, the
result is system dependent.
So, yeah.
I'm sorry, I meant, so yes, you are correct. My first reply was vague,
and might have sounded a bit unpleasant. This was not intended.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/000901cde8d7$98e92000$cabb6000$@allums.com
Re: Is this OK in C++ and C?
On Wed, Jan 2, 2013 at 5:11 AM, Zbigniew Komarnicki cblas...@gmail.com wrote:
On Tuesday 01 of January 2013 08:23:05 you wrote:
C lessons today? (There are newsgroups for C and C++ questions, but, why
not?)
Yes :-)
I wanted to prohibit user to assign negative value to a variable.
This variable is later passed to a recurrence function as
argument and of course I got segmentation fault, because
the function is called 4294967291 times.
I guess you mean recursive function. (Isn't English fun? Hang in there.)
Usually, when you want to catch negative parameters, you also want to
catch positive parameters that are too large. In this case, I'm sure
you do. As someone else pointed out, that means you want to explicitly
range-check your parameters. (And your parameters should be signed,
and large enough, to allow the range checks.)
With recursive calls, I find it useful to define a doorway function
whose sole purpose is to do the range check and pass the valid calls
on to the recursive function. That provides the control you need on
the range check (and gives you a place to define return values for
out-of-range conditions), and it gets the range check out of the way
in the recursive part, where repeated range checks really slow things
down.
This took me a couple of years to figure out, but unsigned types are
not for enforcing range. They are strictly for optimization. For
example (in C, not C++):
int doorway( int p1, int * result )
{
/* Note that this constant upper limit is not necessarily SHRT_MAX
from limits.h */
if ( ( p1 0 ) || ( p1 0x7fff ) )
{ return BAD_RANGE;
}
* result = recurse( (unsigned short) p1 )
...
return GOOD_RANGE;
}
unsigned short recurse( unsigned short p1 )
{
...
intermediate = recurse( /* some expression that never goes
negative or exceeds USHRT_MAX */ );
...
}
I was very surprised when I discover that this code was compiled
without any warning. I thought if a variable is 'unsigned int'
then this is not allowed to assign negative value.
That's all.
Thank you very much.
Have fun!
--
Joel Rees
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caar43ipwyvcvr4fgdrqkb2l5eynw+e3g2_nw-0ywuwoht6m...@mail.gmail.com
Re: Is this OK in C++ and C?
On Wednesday 02 of January 2013 16:00:50 you wrote:
I wanted to prohibit user to assign negative value to a variable.
This variable is later passed to a recurrence function as
argument and of course I got segmentation fault, because
the function is called 4294967291 times.
I guess you mean recursive function. (Isn't English fun? Hang in there.)
Yes, you are right.
[...]
This took me a couple of years to figure out, but unsigned types are
not for enforcing range. They are strictly for optimization. For
example (in C, not C++):
int doorway( int p1, int * result )
{
/* Note that this constant upper limit is not necessarily SHRT_MAX
from limits.h */
if ( ( p1 0 ) || ( p1 0x7fff ) )
{ return BAD_RANGE;
}
* result = recurse( (unsigned short) p1 )
...
return GOOD_RANGE;
}
unsigned short recurse( unsigned short p1 )
{
...
intermediate = recurse( /* some expression that never goes
negative or exceeds USHRT_MAX */ );
...
}
Thank you very much again for sharing your knowledge.
Have fun!
--
Joel Rees
Zbigniew
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201301022321.59779.cblas...@gmail.com
Re: Is this OK in C++ and C?
* Zbigniew Komarnicki: Is this OK or is this a bug, when the wariable 'n' is initializing by negative value? There no any warning. Is this normal? I know that value -5 is converted to unsigned but probably this should by printed a warning, when this is a constant value. What do you think about this? $ g++ -Wsign-conversion t.cc t.cc: In function ‘int main()’: t.cc:7:25: warning: negative integer implicitly converted to unsigned type [-Wsign-conversion] This is with GCC 4.7 in wheezy. This warning isn't in -Wall or -Wextra, probably because the false-positive rate is atrocious. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ip7hqher@mid.deneb.enyo.de
RE: Is this OK in C++ and C?
Joe Pfeiffer
Jari Fredriksson ja...@iki.fi writes:
31.12.2012 20:33, Zbigniew Komarnicki kirjoitti:
Is this OK or is this a bug, when the wariable 'n' is
initializing by negative value? There no any warning.
Is this normal? I know that value -5 is converted
to unsigned but probably this should by printed a warning,
when this is a constant value. What do you think about this?
// prog.cpp
#include iostream
using namespace std;
int main()
{
const unsigned int n = -5;
cout The variable n is: n endl;
return 0;
}
Results:
$ g++ -Wall -W prog.cpp -o prog
$ ./prog
The variable n is: 4294967291
Thank you.
This is a known bug in Debian GNU/Linux. Happy new year ;)
Where does the standard require a warning in this case? If no warning
is required, the behavior is not a bug.
It is a bug, just not a compiler bug. It is a bug in the user program.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/014901cde812$7c4a9390$74dfbab0$@allums.com
RE: Is this OK in C++ and C?
Is this OK or is this a bug, when the wariable 'n' is
initializing by negative value? There no any warning.
Is this normal? I know that value -5 is converted
to unsigned but probably this should by printed a warning,
when this is a constant value. What do you think about this?
// prog.cpp
#include iostream
using namespace std;
int main()
{
const unsigned int n = -5;
cout The variable n is: n endl;
return 0;
}
Results:
$ g++ -Wall -W prog.cpp -o prog
$ ./prog
The variable n is: 4294967291
This is expected behavior, but not defined by the standard because the result
is not portable. That is, a rollover value will occur, but it could vary
depending on the width of an int, and possibly by the binary representation.
As far as I know all systems that Debian with gcc runs on are two's complement,
but still...
I cannot speak to the C++11 standard because ISO/ANSI are not asking a
reasonable price for the specification docs, and I can't afford the price.
A good compiler *may* warn you about this, but it may not do so by default.
You may have to turn the warnings on. Note: gcc's -Wall is tricky. You may
still not get what you expect.
This kind of type shenanigan is allowed in C/C++ because of silent standard
conversions. A strongly-(enough)-typed language will not permit conversions to
or from signed-unsigned without a cast or a conversion function. C/C++
allows this because there is no loss of significant digits (precision).
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/014b01cde813$cf3879e0$6da96da0$@allums.com
Re: Is this OK in C++ and C?
Mark Allums m...@allums.com writes:
Is this OK or is this a bug, when the wariable 'n' is
initializing by negative value? There no any warning.
Is this normal? I know that value -5 is converted
to unsigned but probably this should by printed a warning,
when this is a constant value. What do you think about this?
// prog.cpp
#include iostream
using namespace std;
int main()
{
const unsigned int n = -5;
cout The variable n is: n endl;
return 0;
}
Results:
$ g++ -Wall -W prog.cpp -o prog
$ ./prog
The variable n is: 4294967291
This is expected behavior, but not defined by the standard because the
result is not portable. That is, a rollover value will occur, but it
could vary depending on the width of an int, and possibly by the
binary representation. As far as I know all systems that Debian with
gcc runs on are two's complement, but still...
I believe it is indeed defined behavior.
6.3.1.3 Signed and unsigned integers
1 When a value with integer type is converted to another integer type other
than _Bool, if
the value can be represented by the new type, it is unchanged.
2 Otherwise, if the new type is unsigned, the value is converted by repeatedly
adding or
subtracting one more than the maximum value that can be represented in the
new type
until the value is in the range of the new type.49)
I cannot speak to the C++11 standard because ISO/ANSI are not asking a
reasonable price for the specification docs, and I can't afford the
price.
A good compiler *may* warn you about this, but it may not do so by
default. You may have to turn the warnings on. Note: gcc's -Wall is
tricky. You may still not get what you expect.
This kind of type shenanigan is allowed in C/C++ because of silent
standard conversions. A strongly-(enough)-typed language will not
permit conversions to or from signed-unsigned without a cast or a
conversion function. C/C++ allows this because there is no loss of
significant digits (precision).
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1btxr0kav5@snowball.wb.pfeifferfamily.net
Re: Is this OK in C++ and C?
Jerry Stuckle jstuc...@attglobal.net writes: On 12/31/2012 7:30 PM, Joe Pfeiffer wrote: Jari Fredriksson ja...@iki.fi writes: This is a known bug in Debian GNU/Linux. Happy new year ;) Where does the standard require a warning in this case? If no warning is required, the behavior is not a bug. I don't have a copy of the standard any more, but IIRC it does need a warning. It requires a conversion from signed to unsigned, which can cause incorrect data (as in this case). Promotions (i.e. short to int, float to double) will never cause a loss of data, and do not require warnings. But I also admit it's been several years since I looked at the spec and my memory isn't what it used to be (at least that's what my wife tells me). Looking into it a bit more, I can't find a place where the C99 standard requires *any* warnings. In particular: Annex I (informative) Common warnings 1 An implementation may generate warnings in many situations, none of which are specified as part of this International Standard. The following are a few of the more common situations. (a list of warnings follows) A search doesn't turn up the string warn anywhere in the standard except in this annex. (granted, I don't have the final standard, just a draft from 2005. But still...) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1bpq1okaov@snowball.wb.pfeifferfamily.net
Re: Is this OK in C++ and C?
On Tuesday 01 of January 2013 08:23:05 you wrote: C lessons today? (There are newsgroups for C and C++ questions, but, why not?) Yes :-) I wanted to prohibit user to assign negative value to a variable. This variable is later passed to a recurrence function as argument and of course I got segmentation fault, because the function is called 4294967291 times. I was very surprised when I discover that this code was compiled without any warning. I thought if a variable is 'unsigned int' then this is not allowed to assign negative value. That's all. Thank you very much. -- Joel Rees -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201301012111.58075.cblas...@gmail.com
Re: Is this OK in C++ and C?
* On 2013 01 Jan 14:14 -0600, Zbigniew Komarnicki wrote: On Tuesday 01 of January 2013 08:23:05 you wrote: C lessons today? (There are newsgroups for C and C++ questions, but, why not?) Yes :-) I wanted to prohibit user to assign negative value to a variable. This variable is later passed to a recurrence function as argument and of course I got segmentation fault, because the function is called 4294967291 times. Then you will need to bounds test the user input. I was very surprised when I discover that this code was compiled without any warning. I thought if a variable is 'unsigned int' then this is not allowed to assign negative value. Consider instead that the code is giving you the value of MAX UNSIGNED INT - 5. In other words, the code is allowing you to count backwards from the maximum integer unsigned value on your system. That's how I understand it. - Nate -- The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true. Ham radio, Linux, bikes, and more: http://www.n0nb.us -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130101203334.gr1...@n0nb.us
Re: Is this OK in C++ and C?
Zbigniew Komarnicki cblas...@gmail.com writes: I wanted to prohibit user to assign negative value to a variable. This variable is later passed to a recurrence function as argument and of course I got segmentation fault, because the function is called 4294967291 times. You MUST check the input. Consider a user who has an int with the value he wants to pass. If there were a check, he'd just write: func(unsigned int(x)) to get the thing to compile. Or a user who in error computes a silly large positive value by any nunmber of means. There are languages which attempt to do bounds checking statically, but C isn't like that - which is why buffer overflow still is the friend of the malware writer. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5gcczhh@aptiva.optonline.net
Re: Is this OK in C++ and C?
01.01.2013 22:11, Zbigniew Komarnicki kirjoitti: I was very surprised when I discover that this code was compiled without any warning. I thought if a variable is 'unsigned int' then this is not allowed to assign negative value. That's all. Indeed that is all. C and C++ are light weight code generators, and most such checks must be coded, they are not generated by the compiler. There are other languages, like Ada, and Pascal too, being more pedantic for such issues. But they generate usually more bloated code, as the compiler just creates the checks into it. -- Q: What is the burning question on the mind of every dyslexic existentialist? A: Is there a dog? signature.asc Description: OpenPGP digital signature
Re: Is this OK in C++ and C?
On Tue, 2013-01-01 at 11:41 -0700, Joe Pfeiffer wrote: Looking into it a bit more, I can't find a place where the C99 standard requires *any* warnings. In particular: Annex I (informative) Common warnings 1 An implementation may generate warnings in many situations, none of which are specified as part of this International Standard. The following are a few of the more common situations. (a list of warnings follows) A search doesn't turn up the string warn anywhere in the standard except in this annex. But it probably has quite a few occurrences of 'diagnostic', the C++ standard does; and it states that a 'diagnostic message' shall be issued if a program breaks the rules of the language except where the standard explicitly states no diagnostic is required. With regard to the original question of assigning a negative value to an unsigned integer, this seems to be allowed and defined behaviour. The section on integral conversions has: If the destination type is unsigned, the resulting value is the least unsigned integer congruent to the source integer (modulo 2 n where n is the number of bits used to represent the unsigned type). [Note: In a two’s complement representation, this conversion is conceptual and there is no change in the bit pattern (if there is no truncation). ] -- Tixy -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1357100719.3353.17.ca...@computer5.home
Re: Is this OK in C++ and C?
On Wednesday 02 of January 2013 05:25:19 Tixy wrote: On Tue, 2013-01-01 at 11:41 -0700, Joe Pfeiffer wrote: Looking into it a bit more, I can't find a place where the C99 standard requires *any* warnings. In particular: Annex I (informative) Common warnings 1 An implementation may generate warnings in many situations, none of which are specified as part of this International Standard. The following are a few of the more common situations. (a list of warnings follows) A search doesn't turn up the string warn anywhere in the standard except in this annex. But it probably has quite a few occurrences of 'diagnostic', the C++ standard does; and it states that a 'diagnostic message' shall be issued if a program breaks the rules of the language except where the standard explicitly states no diagnostic is required. With regard to the original question of assigning a negative value to an unsigned integer, this seems to be allowed and defined behaviour. The section on integral conversions has: If the destination type is unsigned, the resulting value is the least unsigned integer congruent to the source integer (modulo 2 n where n is the number of bits used to represent the unsigned type). [Note: In a two’s complement representation, this conversion is conceptual and there is no change in the bit pattern (if there is no truncation). ] Thank you all for your help in understanding my problem. Best regards, Zbigniew -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201301020850.00733.cblas...@gmail.com
Re: Is this OK in C++ and C?
On 12/31/2012 12:33 PM, Zbigniew Komarnicki wrote:
Is this OK or is this a bug, when the wariable 'n' is
initializing by negative value? There no any warning.
Is this normal? I know that value -5 is converted
to unsigned but probably this should by printed a warning,
when this is a constant value. What do you think about this?
// prog.cpp
#include iostream
using namespace std;
int main()
{
const unsigned int n = -5;
cout The variable n is: n endl;
return 0;
}
Results:
$ g++ -Wall -W prog.cpp -o prog
$ ./prog
The variable n is: 4294967291
Thank you.
I do not believe this is an issue. The warning is probably just telling
you that you tried to initialize a constant unsigned int with a signed
value. I don't know if the compiler converts it to 5 or it converts it
to the unsigned value that takes form where -5 would take in a signed
value. I suggest experimenting with that to make sure that any important
behavior dependent on the value works properly. Thought o be honest if
they were planning on using a negative value for something important
they should have left the variable signed.
Yaro
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50e1e1db.7060...@marupa.net
Re: Is this OK in C++ and C?
On 31/12/12 01:33 PM, Zbigniew Komarnicki wrote:
Is this OK or is this a bug, when the wariable 'n' is
initializing by negative value? There no any warning.
Is this normal? I know that value -5 is converted
to unsigned but probably this should by printed a warning,
when this is a constant value. What do you think about this?
// prog.cpp
#includeiostream
using namespace std;
int main()
{
const unsigned int n = -5;
cout The variable n is: n endl;
return 0;
}
Results:
$ g++ -Wall -W prog.cpp -o prog
$ ./prog
The variable n is: 4294967291
Thank you.
C and C++ don't protect you from your own mistakes. Do not expect
consistent behaviour from const unsigned int n = -5;. The results will
almost certainly differ between 32 bit and 64 bit machines, as well as
between x86 and other architectures.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50e1ec7e.2010...@rogers.com
Re: Is this OK in C++ and C?
31.12.2012 20:33, Zbigniew Komarnicki kirjoitti:
Is this OK or is this a bug, when the wariable 'n' is
initializing by negative value? There no any warning.
Is this normal? I know that value -5 is converted
to unsigned but probably this should by printed a warning,
when this is a constant value. What do you think about this?
// prog.cpp
#include iostream
using namespace std;
int main()
{
const unsigned int n = -5;
cout The variable n is: n endl;
return 0;
}
Results:
$ g++ -Wall -W prog.cpp -o prog
$ ./prog
The variable n is: 4294967291
Thank you.
This is a known bug in Debian GNU/Linux. Happy new year ;)
--
April 1
This is the day upon which we are reminded of what we are on the other three
hundred and sixty-four.
-- Mark Twain, Pudd'nhead Wilson's Calendar
signature.asc
Description: OpenPGP digital signature
Re: Is this OK in C++ and C?
Jari Fredriksson ja...@iki.fi writes:
31.12.2012 20:33, Zbigniew Komarnicki kirjoitti:
Is this OK or is this a bug, when the wariable 'n' is
initializing by negative value? There no any warning.
Is this normal? I know that value -5 is converted
to unsigned but probably this should by printed a warning,
when this is a constant value. What do you think about this?
// prog.cpp
#include iostream
using namespace std;
int main()
{
const unsigned int n = -5;
cout The variable n is: n endl;
return 0;
}
Results:
$ g++ -Wall -W prog.cpp -o prog
$ ./prog
The variable n is: 4294967291
Thank you.
This is a known bug in Debian GNU/Linux. Happy new year ;)
Where does the standard require a warning in this case? If no warning
is required, the behavior is not a bug.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1by5gdkanh@snowball.wb.pfeifferfamily.net
Re: Is this OK in C++ and C?
On 12/31/2012 7:30 PM, Joe Pfeiffer wrote:
Jari Fredriksson ja...@iki.fi writes:
31.12.2012 20:33, Zbigniew Komarnicki kirjoitti:
Is this OK or is this a bug, when the wariable 'n' is
initializing by negative value? There no any warning.
Is this normal? I know that value -5 is converted
to unsigned but probably this should by printed a warning,
when this is a constant value. What do you think about this?
// prog.cpp
#include iostream
using namespace std;
int main()
{
const unsigned int n = -5;
cout The variable n is: n endl;
return 0;
}
Results:
$ g++ -Wall -W prog.cpp -o prog
$ ./prog
The variable n is: 4294967291
Thank you.
This is a known bug in Debian GNU/Linux. Happy new year ;)
Where does the standard require a warning in this case? If no warning
is required, the behavior is not a bug.
I don't have a copy of the standard any more, but IIRC it does need a
warning. It requires a conversion from signed to unsigned, which can
cause incorrect data (as in this case).
Promotions (i.e. short to int, float to double) will never cause a loss
of data, and do not require warnings.
But I also admit it's been several years since I looked at the spec and
my memory isn't what it used to be (at least that's what my wife tells me).
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50e24055.3090...@attglobal.net
Re: Is this OK in C++ and C?
C lessons today? (There are newsgroups for C and C++ questions, but, why not?)
On Tue, Jan 1, 2013 at 3:33 AM, Zbigniew Komarnicki cblas...@gmail.com wrote:
Is this OK or is this a bug, when the wariable 'n' is
initializing by negative value? There no any warning.
Is this normal?
Depends on the compiler and the settings.
I know that value -5 is converted
to unsigned
Well, you think you do from some past experience, perhaps, but, no,
that is not what you should expect to happen.
but probably this should by printed a warning,
when this is a constant value. What do you think about this?
Rather have warnings when implicit conversions on variables or complex
expressions might lose significance. That's why the compiler allows
some tuning of the warnings and errors returned. (And why the standard
allows the tuning within standard behavior.)
// prog.cpp
#include iostream
using namespace std;
int main()
{
const unsigned int n = -5;
So, what exactly are you trying to do here?
That could be perfectly valid code in certain cases.
cout The variable n is: n endl;
return 0;
}
Results:
$ g++ -Wall -W prog.cpp -o prog
-pedantic is another useful option, not that it helps here.
$ ./prog
The variable n is: 4294967291
Well, it looks about right. Lessee,
---
user@beast;~$ bc
bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
scale = 20
2^32 - 5
4294967291
---
Yep. What you got is what I would expect in most cases on modern hardware.
Were you expecting, perhaps, 18446744073709551611 or 65531?
Perhaps, 2147483643? (What would happen on a ones complement CPU/runtime?)
Thank you.
Try this code to see if it helps you understand:
int main()
{
const unsigned int n = -5;
char c = n;
cout The variable n is: n and c is: (int) c endl;
/* etc. */
--
Joel Rees
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caar43iobnw0uz4igojqqbjvk6gb+rqd+6g-2c-gam2p9+cx...@mail.gmail.com
