digitalmars.D.bugs - [Issue 1535] New: incorrect casting of 8 bit quantities to longer precision
- d-bugmail puremagic.com (50/50) Sep 27 2007 http://d.puremagic.com/issues/show_bug.cgi?id=1535
- d-bugmail puremagic.com (17/17) Sep 27 2007 http://d.puremagic.com/issues/show_bug.cgi?id=1535
- d-bugmail puremagic.com (6/6) Sep 27 2007 http://d.puremagic.com/issues/show_bug.cgi?id=1535
- d-bugmail puremagic.com (6/6) Sep 28 2007 http://d.puremagic.com/issues/show_bug.cgi?id=1535
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
http://d.puremagic.com/issues/show_bug.cgi?id=1535
shro8822 vandals.uidaho.edu changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
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
http://d.puremagic.com/issues/show_bug.cgi?id=1535
See also:
http://www.digitalmars.com/d/type.html
char is unsigned, so its behavior is also correct.
--
Sep 27 2007
http://d.puremagic.com/issues/show_bug.cgi?id=1535 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









d-bugmail puremagic.com 