www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - Bug: cast to int is required where it shouldn't

reply Id <Id_member pathlink.com> writes:
<[COPIED from general directory]>

There, I've found a big cockroach :) :

[code]
import std.c.stdio;

public static void main(char[][] args)
{
static int[] vector=[0xAABBCCDD, 0xDDCCBBAA, 0x11223344, 0x55667788];
for(int i=0; i<vector.length; i++) printf("vector[%d]: %d\n",i, vector[i]);
}
[/code]

test.d(5) cannot implicitly convert expression 2864434397 of type uint to int.
test.d(5) cannot implicitly convert expression 3721182122 of type uint to int.

(It should be assumed that the first two numbers are negative!...). 
This solves the problem, but I don't see the point of why a cast to int is
required:

[code]
import std.c.stdio;

public static void main(char[][] args)
{
static int[] vector=[cast(int) 0xAABBCCDD, cast (int) 0xDDCCBBAA, 0x11223344,
0x55667788];
for(int i=0; i<vector.length; i++) printf("vector[%d]: %d\n",i, vector[i]);
}
[/code]

Another bug that hasn't been corrected in D (it's there for quite a while!) is
the initialization issue:

[code]
import std.c.stdio;

public static void main(char[][] args)
{
int[] vector=[0x12345678, 0x38FF00CC, 0x11223344, 0x55667788];
for(int i=0; i<vector.length; i++) printf("vector[%d]: %d\n", i, vector[i]);
}
[/code]

test.d(5) variable vector is not a static and cannot have static initializer
Aug 23 2004
parent reply J C Calvarese <jcc7 cox.net> writes:
Id wrote:

 <[COPIED from general directory]>
 
 There, I've found a big cockroach :) :
 
 [code]
 import std.c.stdio;
 
 public static void main(char[][] args)
 {
 static int[] vector=[0xAABBCCDD, 0xDDCCBBAA, 0x11223344, 0x55667788];
 for(int i=0; i<vector.length; i++) printf("vector[%d]: %d\n",i, vector[i]);
 }
 [/code]
 
 test.d(5) cannot implicitly convert expression 2864434397 of type uint to int.
 test.d(5) cannot implicitly convert expression 3721182122 of type uint to int.
 
 (It should be assumed that the first two numbers are negative!...). 


If I understand what you're saying right, the compiler has required a 
cast (by design) since DMD 0.50:

<quote>
Changed implicit conversion rules for integral types; implicit 
conversions are not allowed if the value would change. For example:

	byte  b = 0x10;		// ok
	ubyte c = 0x100;	// error
	byte  d = 0x80;		// error
	ubyte e = 0x80;		// ok
</quote>
	
from http://www.digitalmars.com/d/changelog.html#new050

I don't remember the discussion, but I'm sure it's supposed to protect 
us from hidden bugs.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
Aug 23 2004
next sibling parent Regan Heath <regan netwin.co.nz> writes:
On Mon, 23 Aug 2004 19:54:59 -0500, J C Calvarese <jcc7 cox.net> wrote:

 Id wrote:

 <[COPIED from general directory]>

 There, I've found a big cockroach :) :

 [code]
 import std.c.stdio;

 public static void main(char[][] args)
 {
 static int[] vector=[0xAABBCCDD, 0xDDCCBBAA, 0x11223344, 0x55667788];
 for(int i=0; i<vector.length; i++) printf("vector[%d]: %d\n",i, 
 vector[i]);
 }
 [/code]

 test.d(5) cannot implicitly convert expression 2864434397 of type uint 
 to int.
 test.d(5) cannot implicitly convert expression 3721182122 of type uint 
 to int.

 (It should be assumed that the first two numbers are negative!...).


 If I understand what you're saying right, the compiler has required a 
 cast (by design) since DMD 0.50:

 <quote>
 Changed implicit conversion rules for integral types; implicit 
 conversions are not allowed if the value would change. For example:

 	byte  b = 0x10;		// ok
 	ubyte c = 0x100;	// error
 	byte  d = 0x80;		// error
 	ubyte e = 0x80;		// ok
 </quote>
 	
 from http://www.digitalmars.com/d/changelog.html#new050

 I don't remember the discussion, but I'm sure it's supposed to protect 
 us from hidden bugs.


Ahh of course, so what is happening here is due to the above and to this 
statement:
http://www.digitalmars.com/d/lex.html#integerliteral

"The type of the integer is resolved as follows:

If it is decimal it is the last representable of ulong, long, or int.
If it is not decimal, it is the last representable of ulong, long, uint, 
or int.
If it has the 'u' suffix, it is the last representable of ulong or uint.
If it has the 'l' suffix, it is the last representable of ulong or long.
If it has the 'u' and 'l' suffixes, it is ulong."

As you have written '0xAABBCCDD' the rule 'If it is not decimal, it is the 
last representable of ulong, long, uint, or int' applies making the 
constant a uint. (as 0xAABBCCDD is too big for a signed int, yet not too 
big for an unsigned one)

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 23 2004
prev sibling parent reply Id <Id_member pathlink.com> writes:
If I understand what you're saying right, the compiler has required a 
cast (by design) since DMD 0.50:

<quote>
Changed implicit conversion rules for integral types; implicit 
conversions are not allowed if the value would change. For example:

	byte  b = 0x10;		// ok
	ubyte c = 0x100;	// error
	byte  d = 0x80;		// error
	ubyte e = 0x80;		// ok
</quote>
	
from http://www.digitalmars.com/d/changelog.html#new050



I don't remember the discussion, but I'm sure it's supposed to protect 
us from hidden bugs.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/


Protect us from bugs? Which kind of bug could be derived from that? ;_;.
Java accepts those hex values without problems (as it should)!

What I think Walter did to protect us from hidden bugs was requiring a cast when
you want to turn a number (int) into a pointer (int*) :) .
Aug 24 2004
parent reply J C Calvarese <jcc7 cox.net> writes:
Id wrote:

If I understand what you're saying right, the compiler has required a 
cast (by design) since DMD 0.50:

<quote>
Changed implicit conversion rules for integral types; implicit 
conversions are not allowed if the value would change. For example:

	byte  b = 0x10;		// ok
	ubyte c = 0x100;	// error
	byte  d = 0x80;		// error
	ubyte e = 0x80;		// ok
</quote>
	


 

from http://www.digitalmars.com/d/changelog.html#new050


 
 

I don't remember the discussion, but I'm sure it's supposed to protect 
us from hidden bugs.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/


 
 
 Protect us from bugs? Which kind of bug could be derived from that? ;_;.
 Java accepts those hex values without problems (as it should)!


Java does it so it must be right, huh? ;)

Maybe you don't want a negative number, maybe you wanted a larger 
integar that the storage space allows. I don't know what the reason is, 
but I'm sure there is a reason. I tried looking for a reason in the old 
newsgroup, but I couldn't find any. If you want to do any searching, 
these links might help:

http://www.digitalmars.com/advancedsearch.html

dmd 0.50 release
http://www.digitalmars.com/drn-bin/wwwnews?D/9550


-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
Aug 24 2004
parent reply Id <Id_member pathlink.com> writes:
In article <cggotj$1gs5$1 digitaldaemon.com>, J C Calvarese says...


Maybe you don't want a negative number, maybe you wanted a larger 
integar that the storage space allows. I don't know what the reason is, 
but I'm sure there is a reason. I tried looking for a reason in the old 
newsgroup, but I couldn't find any. If you want to do any searching, 
these links might help:

http://www.digitalmars.com/advancedsearch.html

dmd 0.50 release
http://www.digitalmars.com/drn-bin/wwwnews?D/9550


Thanks for the links. :)
I suppose that when I'm declaring a SIGNED int I'm already aware of 2's
Complement aritmethics and that anything over 0x7FFF_FFFF is negative. ;_;

I also have tested that:

[code]
int main()
{
int a=0x8000_0000;          //error
printf("a: 0x%x\n", a);
return 0;
}
[/code]

However, this:
[code]
int main()
{
uint a=0x8000_0000;
int b=a;                 //ok
printf("b: 0x%x\n", b);
return 0;
}
[/code]

If the above isn't allowed, why this workaround is, then?  _ ' .
That's inconsistent. A cast should only be used when you are converting types,
not when you are declaring something that is perfectly valid, even if it's
negative.
Aug 25 2004
next sibling parent "Walter" <newshound digitalmars.com> writes:
"Id" <Id_member pathlink.com> wrote in message
news:cghjnv$1tue$1 digitaldaemon.com...

 In article <cggotj$1gs5$1 digitaldaemon.com>, J C Calvarese says...


Maybe you don't want a negative number, maybe you wanted a larger
integar that the storage space allows. I don't know what the reason is,
but I'm sure there is a reason. I tried looking for a reason in the old
newsgroup, but I couldn't find any. If you want to do any searching,
these links might help:




The reason is to catch what are essentially overflows in the numeric
literals.


 If the above isn't allowed, why this workaround is, then?  _ ' .
 That's inconsistent.


Yes, it is inconsistent. But the latter would require a fairly expensive
runtime check.


 A cast should only be used when you are converting types,
 not when you are declaring something that is perfectly valid, even if it's
 negative.


In this case, you are converting types, from a very large unsigned type to a
negative signed one.
Aug 25 2004
prev sibling parent Arcane Jill <Arcane_member pathlink.com> writes:
In article <cghjnv$1tue$1 digitaldaemon.com>, Id says...


Maybe you don't want a negative number, maybe you wanted a larger 
integar that the storage space allows.





I suppose that when I'm declaring a SIGNED int I'm already aware of 2's
Complement aritmethics and that anything over 0x7FFF_FFFF is negative. ;_;


The way I look at it, anything over 0x7FFFFFFF is just a large positive number.
Writing 0x80000000 instead of 2147483648 is just a change of radix. Changing the
radix from ten to sixteen doesn't make a number negative. If you want a negative
number, use a minus sign, or an explicit cast.

I'd say D's got this right.

Arcane Jill
Aug 25 2004