Re: Why are unsigned to signed conversions implicit and don't emit a warning?
On 04/11/2011 02:42 AM, bearophile wrote: I and Don have asked (in Bugzilla and elsewhere) to change the built-in names into sbyte and ubyte, to avoid the common confusions between signed and unsigned bytes in D, but Walter was deaf to this. I think a good naming scheme would be: * signed : int8 .. int64 * unsigned : nat8 .. nat64 (since natural number more or less means unsigned integer number) already. What do you think? or counting in octets: * signed : int1 .. int8 * unsigned : nat1 .. nat8 (I prefere the latter naming scheme in absolute, but it would be confusing because some languages --and LLVM, I guess-- count in bits.) Denis -- _ vita es estrany spir.wikidot.com
Re: Why are unsigned to signed conversions implicit and don't emit a warning?
On Sun, Apr 10, 2011 at 7:57 PM, Jonathan M Davis jmdavisp...@gmx.com wrote: Andrej Mitrovic: I just had a little bug in my code. In the WindowsAPI, there's this alias: alias ubyte BYTE; Unfortunately I didn't check for this, and I erroneously assumed BYTE was a signed value (blame it on my lack of coffee). I and Don have asked (in Bugzilla and elsewhere) to change the built-in names into sbyte and ubyte, to avoid the common confusions between signed and unsigned bytes in D, but Walter was deaf to this. But what really surprises me is that these unsigned to signed conversions happen implicitly. I didn't even get a warning, even though I have all warning switches turned on. Add your vote here (I have voted this), a bug report from 07 2006, but Walter doesn't like this warning, and warnings in general too: http://d.puremagic.com/issues/show_bug.cgi?id=259 Personally, I see _zero_ value in renaming byte, int, etc. to sbyte, sint, etc. It's well-known that they're signed. I don't see how adding an extra s would make that any clearer. Their names are perfectly clear as they are. However, I also would have thought that converting between signed and unsigned values would be just as much of an error as narrowing conversions are - such as assigning an int to a byte. And arguably, assigning either an unsigned value to a signed value or vice versa is _also_ a narrowing conversion. So, I would have thought that it would be an error. Apparently not though. I agree completely. The names are fine, we just need to get the conversions right. Yes, they aren't theoretically correct but integers as we define them aren't even integers in the mathematical sense, so the whole system isn't theoretically correct. D's scheme, while not pure, is very natural to use.
Re: Why are unsigned to signed conversions implicit and don't emit a warning?
On 2011/04/11 09:31 AM, spir wrote: On 04/11/2011 02:42 AM, bearophile wrote: I and Don have asked (in Bugzilla and elsewhere) to change the built-in names into sbyte and ubyte, to avoid the common confusions between signed and unsigned bytes in D, but Walter was deaf to this. I think a good naming scheme would be: * signed : int8 .. int64 * unsigned : nat8 .. nat64 (since natural number more or less means unsigned integer number) already. What do you think? I like the idea of removing all the different integer type names (byte, short, int, long, cent) and replacing them with int8..int64 (I'd still prefer uint8..uint64 though). Then you could use just 'int' to specify using the current system's architecture (and hopefully replace the ugly size_t type). I also think it makes more sense to just use 'int' when you don't really care about the specific size of the value. Unfortunately it would break backwards compatility so it would never make it into D's current state.
Re: Why are unsigned to signed conversions implicit and don't emit a warning?
On 04/11/2011 10:10 AM, SimonM wrote: On 2011/04/11 09:31 AM, spir wrote: On 04/11/2011 02:42 AM, bearophile wrote: I and Don have asked (in Bugzilla and elsewhere) to change the built-in names into sbyte and ubyte, to avoid the common confusions between signed and unsigned bytes in D, but Walter was deaf to this. I think a good naming scheme would be: * signed : int8 .. int64 * unsigned : nat8 .. nat64 (since natural number more or less means unsigned integer number) already. What do you think? I like the idea of removing all the different integer type names (byte, short, int, long, cent) and replacing them with int8..int64 (I'd still prefer uint8..uint64 though). Then you could use just 'int' to specify using the current system's architecture (and hopefully replace the ugly size_t type). I also think it makes more sense to just use 'int' when you don't really care about the specific size of the value. Unfortunately it would break backwards compatility so it would never make it into D's current state. Agreed. Same for uint or nat. And no implicit cast, please ;-) Denis -- _ vita es estrany spir.wikidot.com
Re: Why are unsigned to signed conversions implicit and don't emit a warning?
There are some aliases in std.stdint
Why are unsigned to signed conversions implicit and don't emit a warning?
I just had a little bug in my code. In the WindowsAPI, there's this alias:
alias ubyte BYTE;
Unfortunately I didn't check for this, and I erroneously assumed BYTE was a
signed value (blame it on my lack of coffee). So when I used code like this:
alias Tuple!(byte, red, byte, green, byte, blue) RGBTuple;
RGBTuple GetRGB(COLORREF cref)
{
RGBTuple rgb;
rgb.red = GetRValue(cref);
rgb.green = GetGValue(cref);
rgb.blue = GetBValue(cref);
return rgb;
}
The rgb fields would often end up being -1 (Yes, I know all about how signed vs
unsigned representation works). My fault, yes.
But what really surprises me is that these unsigned to signed conversions
happen implicitly. I didn't even get a warning, even though I have all warning
switches turned on.
I'm pretty sure GCC would complain about this in C code. Visual Studio
certainly complains if I set the appropriate warnings, examples given:
warning C4365: '=' : conversion from 'unsigned int' to 'int', signed/unsigned
mismatch
warning C4365: '=' : conversion from 'unsigned short' to 'short',
signed/unsigned mismatch
Re: Why are unsigned to signed conversions implicit and don't emit a warning?
And I just remembered Tuples can be constructed just like regular structs
(which they are underneath):
RGBTuple GetRGB(COLORREF cref)
{
return RGBTuple(GetRValue(cref), GetGValue(cref), GetBValue(cref));
}
Re: Why are unsigned to signed conversions implicit and don't emit a warning?
Andrej Mitrovic: I just had a little bug in my code. In the WindowsAPI, there's this alias: alias ubyte BYTE; Unfortunately I didn't check for this, and I erroneously assumed BYTE was a signed value (blame it on my lack of coffee). I and Don have asked (in Bugzilla and elsewhere) to change the built-in names into sbyte and ubyte, to avoid the common confusions between signed and unsigned bytes in D, but Walter was deaf to this. But what really surprises me is that these unsigned to signed conversions happen implicitly. I didn't even get a warning, even though I have all warning switches turned on. Add your vote here (I have voted this), a bug report from 07 2006, but Walter doesn't like this warning, and warnings in general too: http://d.puremagic.com/issues/show_bug.cgi?id=259 Bye, bearophile
Re: Why are unsigned to signed conversions implicit and don't emit a warning?
Andrej Mitrovic: I just had a little bug in my code. In the WindowsAPI, there's this alias: alias ubyte BYTE; Unfortunately I didn't check for this, and I erroneously assumed BYTE was a signed value (blame it on my lack of coffee). I and Don have asked (in Bugzilla and elsewhere) to change the built-in names into sbyte and ubyte, to avoid the common confusions between signed and unsigned bytes in D, but Walter was deaf to this. But what really surprises me is that these unsigned to signed conversions happen implicitly. I didn't even get a warning, even though I have all warning switches turned on. Add your vote here (I have voted this), a bug report from 07 2006, but Walter doesn't like this warning, and warnings in general too: http://d.puremagic.com/issues/show_bug.cgi?id=259 Personally, I see _zero_ value in renaming byte, int, etc. to sbyte, sint, etc. It's well-known that they're signed. I don't see how adding an extra s would make that any clearer. Their names are perfectly clear as they are. However, I also would have thought that converting between signed and unsigned values would be just as much of an error as narrowing conversions are - such as assigning an int to a byte. And arguably, assigning either an unsigned value to a signed value or vice versa is _also_ a narrowing conversion. So, I would have thought that it would be an error. Apparently not though. - Jonathan M Davis
