www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 1535] New: incorrect casting of 8 bit quantities to longer precision

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1535

           Summary: incorrect casting of 8 bit quantities to longer
                    precision
           Product: D
           Version: 1.021
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: major
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: grahamc001uk yahoo.co.uk


Casting 8 bit quantities to longer precision does wrong sign extension.
bytes get sign extended and chars do not.
It should be the other way around.

Test program:


// Compiled with Digital Mars D Compiler v1.021
// on Windows XP.
import std.stdio;

void main() {
        char    c8; short c16; int c32;
        byte    b8; ushort b16; uint b32;

        c8 = 0x80;
        b8 = cast(byte) 0x80;

        c16 = cast(short) c8;
        b16 = cast(ushort) b8;

        c32 = cast(int) c8;
        b32 = cast(uint) b8;

        // These asserts are present to prove this is not a feature of
writefln().
        assert(cast(ushort)b8 == 0xFF80);
        assert(cast(uint)b8 == 0xFFFFFF80);

        writefln("c %X", c8);
        writefln("b %X", b8);

        // chars should be sign extended and bytes not sign extended.
        // but the reverse actually happens.

        writefln("c %X", c16);
        writefln("b %X", b16);

        writefln("c %X", c32);
        writefln("b %X", b32);

        // This program generates the following output:
        // c 80
        // b 80
        // c 80
        // b FF80
        // c 80
        // b FFFFFF80

}


--
Sep 27 2007
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1535


shro8822 vandals.uidaho.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




------- Comment #1 from shro8822 vandals.uidaho.edu  2007-09-27 20:43 -------
I think this bug is invalid:

byte should get sign extended as it is a signed value (ubyte is unsigned).
char is not technically a number so I'm not sure what should happen when it is
cast to an int. (or short, or long, etc.) When it is cast to a large char
(wchar or dchar) it should be converted to the equivalent value there (which
bitwise is IIRC the same as a unsigned cast from a ubyte to ushort or uint)
based on that the cast is correct in both cases.

I;m marking this as invalid because one cases is invalid and the other probably
is.


--
Sep 27 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1535





------- Comment #2 from braddr puremagic.com  2007-09-27 21:03 -------
See also:
    http://www.digitalmars.com/d/type.html

char is unsigned, so its behavior is also correct.


--
Sep 27 2007
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1535





------- Comment #3 from bugzilla digitalmars.com  2007-09-28 03:19 -------
This works as designed. bytes are signed, ubytes are unsigned. chars are
unsigned because they have valid values >=0x80, which would screw up if they
were sign extended.


--
Sep 28 2007