Thread overview | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
August 24, 2004 Bug: cast to int is required where it shouldn't | ||||
---|---|---|---|---|
| ||||
<[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 |
August 24, 2004 Re: Bug: cast to int is required where it shouldn't | ||||
---|---|---|---|---|
| ||||
Posted in reply to Id | 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/ |
August 24, 2004 Re: Bug: cast to int is required where it shouldn't | ||||
---|---|---|---|---|
| ||||
Posted in reply to J C Calvarese | 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/ |
August 24, 2004 Re: Bug: cast to int is required where it shouldn't | ||||
---|---|---|---|---|
| ||||
Posted in reply to J C Calvarese | >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*) :) . |
August 25, 2004 Re: Bug: cast to int is required where it shouldn't | ||||
---|---|---|---|---|
| ||||
Posted in reply to Id | 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/ |
August 25, 2004 Re: Bug: cast to int is required where it shouldn't | ||||
---|---|---|---|---|
| ||||
Posted in reply to J C Calvarese | 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. |
August 25, 2004 Re: Bug: cast to int is required where it shouldn't | ||||
---|---|---|---|---|
| ||||
Posted in reply to Id | "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. |
August 25, 2004 Re: Bug: cast to int is required where it shouldn't | ||||
---|---|---|---|---|
| ||||
Posted in reply to Id | 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 |
Copyright © 1999-2021 by the D Language Foundation