www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Another compiler bug? Int to uint comparsion

reply nail <nail_member pathlink.com> writes:
Hello.

Consider following snipet

module test;

int main ( char [] [] args )
{
int a = -1;
uint b = 36;
assert(a < b);

return 0;	
}

The code above compiles ok, but has assertion failture at runtime. If I replace
assert with

assert(cast(int)a < cast(int)b);

no exception will be thrown.

Is it normaly? I think not, if compiler decides to implicitly cast both
arguments to uint hard-find bugs are appear. So I think compiler must cast
arguments in this case to int's or report an error.

PS: I know, I plague all with my bugs, but c'est la vie :)
Feb 06 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
nail wrote:

 int a = -1;
 uint b = 36;
 assert(a < b);

 Is it normaly? I think not, if compiler decides to implicitly cast both
 arguments to uint hard-find bugs are appear. So I think compiler must cast
 arguments in this case to int's or report an error.

I think it's "normal", or at least according to spec: http://www.digitalmars.com/d/type.html:
    5.  Else the integer promotions are done on each operand, followed by:
          1. If both are the same type, no more conversions are done.
          2. If both are signed or both are unsigned, the smaller type is
converted to the larger.
          3. If the signed type is larger than the unsigned type, the unsigned
type is converted to the signed type.
          4. The signed type is converted to the unsigned type. 

I think subclause 4. is what happened to your assert. --anders
Feb 07 2005
parent reply nail <nail_member pathlink.com> writes:
In article <cu77as$vm3$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
nail wrote:

 int a = -1;
 uint b = 36;
 assert(a < b);

 Is it normaly? I think not, if compiler decides to implicitly cast both
 arguments to uint hard-find bugs are appear. So I think compiler must cast
 arguments in this case to int's or report an error.

I think it's "normal", or at least according to spec: http://www.digitalmars.com/d/type.html:
    5.  Else the integer promotions are done on each operand, followed by:
          1. If both are the same type, no more conversions are done.
          2. If both are signed or both are unsigned, the smaller type is
converted to the larger.
          3. If the signed type is larger than the unsigned type, the unsigned
type is converted to the signed type.
          4. The signed type is converted to the unsigned type. 

I think subclause 4. is what happened to your assert.

Thanx, but is this logically? This can be the reason of bugs. In C++ there is warning "signed/unsigned mismatch", I think the same should be in D but as error.
Feb 07 2005
next sibling parent "Walter" <newshound digitalmars.com> writes:
"nail" <nail_member pathlink.com> wrote in message
news:cu7nsp$1un3$1 digitaldaemon.com...
 Thanx, but is this logically? This can be the reason of bugs. In C++ there

 warning "signed/unsigned mismatch", I think the same should be in D but as
 error.

It matches the standard conforming behavior of C and C++.
Feb 08 2005
prev sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"nail" <nail_member pathlink.com> wrote in message 
news:cu7nsp$1un3$1 digitaldaemon.com...
 In article <cu77as$vm3$1 digitaldaemon.com>,
 =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
nail wrote:

 int a = -1;
 uint b = 36;
 assert(a < b);

 Is it normaly? I think not, if compiler decides to implicitly cast 
 both
 arguments to uint hard-find bugs are appear. So I think compiler 
 must cast
 arguments in this case to int's or report an error.

I think it's "normal", or at least according to spec: http://www.digitalmars.com/d/type.html:
    5.  Else the integer promotions are done on each operand, 
 followed by:
          1. If both are the same type, no more conversions are done.
          2. If both are signed or both are unsigned, the smaller 
 type is converted to the larger.
          3. If the signed type is larger than the unsigned type, the 
 unsigned type is converted to the signed type.
          4. The signed type is converted to the unsigned type.

I think subclause 4. is what happened to your assert.

Thanx, but is this logically? This can be the reason of bugs. In C++ there is warning "signed/unsigned mismatch", I think the same should be in D but as error.

Well, D doesn't like warnings. I agree that this is problematic, but D doesn't like warnings. :-(
Feb 08 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Matthew wrote:
 "nail" <nail_member pathlink.com> wrote in message 
 news:cu7nsp$1un3$1 digitaldaemon.com...
 
In article <cu77as$vm3$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

nail wrote:


int a = -1;
uint b = 36;
assert(a < b);

Is it normaly? I think not, if compiler decides to implicitly cast 
both
arguments to uint hard-find bugs are appear. So I think compiler 
must cast
arguments in this case to int's or report an error.

I think it's "normal", or at least according to spec: http://www.digitalmars.com/d/type.html:
   5.  Else the integer promotions are done on each operand, 
followed by:
         1. If both are the same type, no more conversions are done.
         2. If both are signed or both are unsigned, the smaller 
type is converted to the larger.
         3. If the signed type is larger than the unsigned type, the 
unsigned type is converted to the signed type.
         4. The signed type is converted to the unsigned type.

I think subclause 4. is what happened to your assert.

Thanx, but is this logically? This can be the reason of bugs. In C++ there is warning "signed/unsigned mismatch", I think the same should be in D but as error.

Well, D doesn't like warnings. I agree that this is problematic, but D doesn't like warnings. :-(

I wouldn't mind this being made to an error.
Feb 14 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:4210EE43.90003 nospam.org...
 Matthew wrote:
 "nail" <nail_member pathlink.com> wrote in message 
 news:cu7nsp$1un3$1 digitaldaemon.com...

In article <cu77as$vm3$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

nail wrote:


int a = -1;
uint b = 36;
assert(a < b);

Is it normaly? I think not, if compiler decides to implicitly cast 
both
arguments to uint hard-find bugs are appear. So I think compiler 
must cast
arguments in this case to int's or report an error.

I think it's "normal", or at least according to spec: http://www.digitalmars.com/d/type.html:
   5.  Else the integer promotions are done on each operand, 
 followed by:
         1. If both are the same type, no more conversions are 
 done.
         2. If both are signed or both are unsigned, the smaller 
 type is converted to the larger.
         3. If the signed type is larger than the unsigned type, 
 the unsigned type is converted to the signed type.
         4. The signed type is converted to the unsigned type.

I think subclause 4. is what happened to your assert.

Thanx, but is this logically? This can be the reason of bugs. In C++ there is warning "signed/unsigned mismatch", I think the same should be in D but as error.

Well, D doesn't like warnings. I agree that this is problematic, but D doesn't like warnings. :-(

I wouldn't mind this being made to an error.

Well, that's precisely the point I was lamely making. I know Walter predicts that if we do so, it will cause myriad irritations, where 'reasonable' code is made 'unreasonable'. IMO, dmd should have, at this pre-1.0 stage, options for switching such things into warnings, so people can get a feel for whether this prediction is true. I have to say that, since I always make warnings max and treated as errors in C++, I don't spend hours and hours each day putting in 'silly' casts, so I doubt his prediction. But until we can try it, how can anyone know ... ??
Feb 14 2005
parent reply Kris <Kris_member pathlink.com> writes:
It should be noted that while the compiler will silently convert between, say,
uint and int, it halts with an error if you present an int[] unto a uint[]
argument. There's a troubling lack of symmetry to all this, frankly.

- Kris


In article <cuqvuj$1nl5$1 digitaldaemon.com>, Matthew says...
"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:4210EE43.90003 nospam.org...
 Matthew wrote:
 "nail" <nail_member pathlink.com> wrote in message 
 news:cu7nsp$1un3$1 digitaldaemon.com...

In article <cu77as$vm3$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

nail wrote:


int a = -1;
uint b = 36;
assert(a < b);

Is it normaly? I think not, if compiler decides to implicitly cast 
both
arguments to uint hard-find bugs are appear. So I think compiler 
must cast
arguments in this case to int's or report an error.

I think it's "normal", or at least according to spec: http://www.digitalmars.com/d/type.html:
   5.  Else the integer promotions are done on each operand, 
 followed by:
         1. If both are the same type, no more conversions are 
 done.
         2. If both are signed or both are unsigned, the smaller 
 type is converted to the larger.
         3. If the signed type is larger than the unsigned type, 
 the unsigned type is converted to the signed type.
         4. The signed type is converted to the unsigned type.

I think subclause 4. is what happened to your assert.

Thanx, but is this logically? This can be the reason of bugs. In C++ there is warning "signed/unsigned mismatch", I think the same should be in D but as error.

Well, D doesn't like warnings. I agree that this is problematic, but D doesn't like warnings. :-(

I wouldn't mind this being made to an error.

Well, that's precisely the point I was lamely making. I know Walter predicts that if we do so, it will cause myriad irritations, where 'reasonable' code is made 'unreasonable'. IMO, dmd should have, at this pre-1.0 stage, options for switching such things into warnings, so people can get a feel for whether this prediction is true. I have to say that, since I always make warnings max and treated as errors in C++, I don't spend hours and hours each day putting in 'silly' casts, so I doubt his prediction. But until we can try it, how can anyone know ... ??

Feb 14 2005
parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
Agreed (at least on that point)

"Kris" <Kris_member pathlink.com> wrote in message 
news:cus5i7$2qjh$1 digitaldaemon.com...
 It should be noted that while the compiler will silently convert 
 between, say,
 uint and int, it halts with an error if you present an int[] unto a 
 uint[]
 argument. There's a troubling lack of symmetry to all this, frankly.

 - Kris


 In article <cuqvuj$1nl5$1 digitaldaemon.com>, Matthew says...
"Georg Wrede" <georg.wrede nospam.org> wrote in message
news:4210EE43.90003 nospam.org...
 Matthew wrote:
 "nail" <nail_member pathlink.com> wrote in message
 news:cu7nsp$1un3$1 digitaldaemon.com...

In article <cu77as$vm3$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

nail wrote:


int a = -1;
uint b = 36;
assert(a < b);

Is it normaly? I think not, if compiler decides to implicitly 
cast
both
arguments to uint hard-find bugs are appear. So I think compiler
must cast
arguments in this case to int's or report an error.

I think it's "normal", or at least according to spec: http://www.digitalmars.com/d/type.html:
   5.  Else the integer promotions are done on each operand,
 followed by:
         1. If both are the same type, no more conversions are
 done.
         2. If both are signed or both are unsigned, the smaller
 type is converted to the larger.
         3. If the signed type is larger than the unsigned type,
 the unsigned type is converted to the signed type.
         4. The signed type is converted to the unsigned type.

I think subclause 4. is what happened to your assert.

Thanx, but is this logically? This can be the reason of bugs. In C++ there is warning "signed/unsigned mismatch", I think the same should be in D but as error.

Well, D doesn't like warnings. I agree that this is problematic, but D doesn't like warnings. :-(

I wouldn't mind this being made to an error.

Well, that's precisely the point I was lamely making. I know Walter predicts that if we do so, it will cause myriad irritations, where 'reasonable' code is made 'unreasonable'. IMO, dmd should have, at this pre-1.0 stage, options for switching such things into warnings, so people can get a feel for whether this prediction is true. I have to say that, since I always make warnings max and treated as errors in C++, I don't spend hours and hours each day putting in 'silly' casts, so I doubt his prediction. But until we can try it, how can anyone know ... ??


Feb 14 2005