July 25, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=259


Andrei Alexandrescu <andrei@metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |andrei@metalanguage.com
         AssignedTo|nobody@puremagic.com        |andrei@metalanguage.com




--- Comment #10 from Andrei Alexandrescu <andrei@metalanguage.com>  2009-07-24 18:08:49 PDT ---
This needs to be fixed. I'm taking ownership (though Walter will do all the work) in order to not forget. I'll add a unittest to TDPL too. Until then let's vote this up.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
August 25, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=259


Andrei Alexandrescu <andrei@metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|andrei@metalanguage.com     |bugzilla@digitalmars.com
           Severity|normal                      |major




--- Comment #11 from Andrei Alexandrescu <andrei@metalanguage.com>  2009-08-24 22:17:42 PDT ---
Reassigning this to Walter. Walter, any chance you could please bump the priority on fixing this one. I am bumping priority to major, it's an important bug that is getting rather old.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
September 03, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=259


Ellery Newcomer <ellery-newcomer@utulsa.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ellery-newcomer@utulsa.edu




--- Comment #12 from Ellery Newcomer <ellery-newcomer@utulsa.edu>  2009-09-03 08:33:41 PDT ---
This morning I've been tinkering with the DMD source, and I've made an edit to expression.c that appears to fix this issue. How do I submit?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
September 03, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=259


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug@yahoo.com.au




--- Comment #13 from Don <clugdbug@yahoo.com.au>  2009-09-03 08:39:48 PDT ---
(In reply to comment #12)
> This morning I've been tinkering with the DMD source, and I've made an edit to expression.c that appears to fix this issue. How do I submit?

Either create a patch using SVN, and attach it, or just post the lines you changed (Walter doesn't actually use patch files, as far as I can tell). Search for bugs with keyword 'patch' for examples.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
September 03, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=259





--- Comment #14 from Ellery Newcomer <ellery-newcomer@utulsa.edu>  2009-09-03 13:51:16 PDT ---
Okay, so what I have is it checks for

signed cmp unsigned

or vice versa in CmpExp::Semantic just before typeCombine gets called, which works, but then stuff like

1 < 1u

doesn't. So the idea is

signed cmp unsigned

or vice versa is okay if the signed arg is a literal and its value is nonnegative.

This should work fine if sizeof(signed arg) =< sizeof(unsigned arg) because the
value of the signed arg is within the range of the unsigned arg, and
typeCombine should be able to expand the type of the signed arg to that of the
unsigned arg or whatever.
It should work if sizeof(signed arg) > sizeof(unsigned arg) because the value
of the unsigned arg is within the range of the signed arg, and typeCombine
should be able to expand the type of the unsigned arg to that of the signed
arg.

I don't know, maybe this should be happening in typeCombine. Insert the following in expression.c CmpExp::semantic before the line

typeCombine(sc);


    if ( e1->type->isintegral() && e2->type->isintegral()){
        if(e1->type->isunsigned() ^ e2->type->isunsigned()){
            if(!e1->type->isunsigned() &&
                dynamic_cast<IntegerExp*>(e1) &&
                ((sinteger_t) e1->toInteger()) >= 0) goto JustKidding;
            if(!e2->type->isunsigned() &&
                dynamic_cast<IntegerExp*>(e2) &&
                ((sinteger_t) e2->toInteger()) >= 0) goto JustKidding;
            error("comparing signed and unsigned integers");
        }
        JustKidding:;
    }

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
September 08, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=259



--- Comment #15 from Don <clugdbug@yahoo.com.au> 2009-09-08 09:40:30 PDT ---
(In reply to comment #14)
> Okay, so what I have is it checks for
[snip]
> 
> signed cmp unsigned
> 
> or vice versa is okay if the signed arg is a literal and its value is nonnegative.

In D2, it's possible to a lot better than this. With the new D2 rules for
implicit conversion between integral types (range-based), it should be enough
to require that one of the types must implicitly convert to the other. This
doesn't quite work yet, since range-based addition (for example) is not yet
implemented.
This will mean that stuff like:
byte b;
uint u;
b = -67;
if (u < b + 0x100) ...
is OK because although b + 0x100 is signed, it can never be less than 1, so it
can safely be converted to unsigned.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
September 08, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=259



--- Comment #16 from Ellery Newcomer <ellery-newcomer@utulsa.edu> 2009-09-08 10:43:00 PDT ---
Cool. That sounds like a much better solution than the patch I posted.

Concerning my patch, I just realized that comparison with unsigned and zero generally doesn't make sense either, except maybe

{unsigned} > 0

so now I have

    if ( e1->type->isintegral() && e2->type->isintegral()){
        if(e1->type->isunsigned() ^ e2->type->isunsigned()){
            if(!e1->type->isunsigned() && dynamic_cast<IntegerExp*>(e1)){
                sinteger_t v1 = ((sinteger_t) e1->toInteger());
                if(v1 > 0) goto JustKidding;
                // 0 < uns or 0 !>= uns okay
                else if(v1 == 0 && (op == TOKlt || op == TOKul))
                    goto JustKidding;
            }else if(dynamic_cast<IntegerExp*>(e2)){
                sinteger_t v2 = ((sinteger_t) e2->toInteger());
                if(v2 > 0) goto JustKidding;
                // uns > 0 or uns !<= 0 okay
                else if(v2 == 0 && (op == TOKgt || op == TOKug))
                    goto JustKidding;
            }
            error("comparing signed and unsigned integers");
        }
        JustKidding:;
    }

in case anyone plans to commit it

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
November 18, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=259


Witold Baryluk <baryluk@smp.if.uj.edu.pl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |baryluk@smp.if.uj.edu.pl


--- Comment #17 from Witold Baryluk <baryluk@smp.if.uj.edu.pl> 2009-11-18 13:13:14 PST ---
Hi,

I today found remarkable bug:

int k = -1;
uint n = 7;
assert(k < n);


Code above should execute without proble, but dmd it computing false as value of (k<n) which absolutly nonsensical. casting n to int, resolves problem

int k = -1;
uint n = 7;
assert(k < cast(T)n);

How it can be so long time not resolved?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
November 26, 2010
http://d.puremagic.com/issues/show_bug.cgi?id=259


Andrei Alexandrescu <andrei@metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |critical


--- Comment #18 from Andrei Alexandrescu <andrei@metalanguage.com> 2010-11-26 10:43:45 PST ---
Escalating severity of this dangerous issue. Has 11 votes, too.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
January 14, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=259


Éric Estièvenart <eric.estievenart@free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eric.estievenart@free.fr


--- Comment #19 from Éric Estièvenart <eric.estievenart@free.fr> 2011-01-14 11:55:24 PST ---
Indeed this is rather critical; I hit it in a simple precondition like:
void insert( Object o, int ndx = -1 ) // -1 means last
  in { assert( ndx >= -1 && ndx <= somearray.length ); }

forcing to add a cast everywhere would be very painful...

The following code should compile without error and pass:
void main()
{
  uint ulen = 0;
  int ndx = -1;
  assert( -1 <= ulen );
  assert( ndx <= ulen );
}

If it generates warnings is another issue...

// This one should compile too
void func2()
{
  uint u;
  // should not compile (or at least warn): always yields to true
  static assert( !is( typeof( u >= 0 ) ) );
  static assert( !is( typeof( u >= -1 ) ) );
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------