<[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

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/

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/

>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*) :) .

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/

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.

"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.

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