[Issue 13387] New: Bug with arithmetic opertions on integer types smaller than int

via Digitalmars-d-bugs digitalmars-d-bugs at puremagic.com
Wed Aug 27 23:25:06 PDT 2014


https://issues.dlang.org/show_bug.cgi?id=13387

          Issue ID: 13387
           Summary: Bug with arithmetic opertions on integer types smaller
                    than int
           Product: D
           Version: unspecified
          Hardware: x86_64
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P1
         Component: DMD
          Assignee: nobody at puremagic.com
          Reporter: neuranuz at gmail.com

I consider it is buggy behaviour that when I sum two values of the same type
and I get resulting value of another type. And also when sum two integer values
of different type I think that resulting value must be biggest in size type of
these two, but not other third type that is not expected to be.


//----------
void main()
{
    ubyte a = 1;
    ushort b = 2;
    ushort c = a + b;
}
// Error: cannot implicitly convert expression (cast(int)a + cast(int)b) of
type int to ushort 
//----------
void main()
{
    byte a = 1;
    byte b = 2;
    byte c = a + b;    

}
//----------
void main()
{
    short a = 1;
    short b = 2;
    short c = a - b;    

}
//----------

Also I consider assigning uint to int without explicit cast is senseless and
unsafe
//----------
void main()
{
    uint a = uint.max;
    int c = a; //This must issue an error
}
//----------

But this could be allowed because ubyte max number could be stored in int or in
short
//----------
void main()
{
    ubyte a = ubyte.max;
    short b = a; //Is OK
    int c = a; //Is OK
}
//----------

Also implicit cast from byte, short. etc. with combination with *alias this*
becomes source of silent bugs. But I don't know what to do with it, because
forbidding all the integer implicit casts is not good to, because assigning
short -> int is useful in most cases.

Example that demonstrates these silent bugs with using alias this and integers:

//----------
import std.stdio, std.typecons;

interface ListControl
{
    @property {
        void selValue(int value);

        void selValue(Nullable!int value);
    }
}


class CheckBoxList: ListControl
{
    override @property {
        void selValue(int value)
        {
            writeln("value: int");
        }

        void selValue(Nullable!int value)
        {
            writeln("value: Nullable!int");
        }
    }

}

void main()
{
    //Someone considered to make it of byte type 
    //instead of int to save memory
    Nullable!byte myValue; //it is null/uninitialized

    //Creating object
    auto checkBoxList = new CheckBoxList;

    //Let's assign value to our property
    //You see that types don't match. But let's imagine that it is a
complicated project
    //and class implementation and *myValue* located in different modules so
programmer don't remember right type
    checkBoxList.selValue = myValue; //This just silently fails in runtime
without some compile-time error
}
//----------

More simple example shows that Nullable based on integer types is source of
silent (at compile-time) bugs

//----------
import std.typecons;

void main()
{
    Nullable!byte a;
    Nullable!int b;

    b = a; //This fails in runtime
}
//----------

--


More information about the Digitalmars-d-bugs mailing list