http://d.puremagic.com/issues/show_bug.cgi?id=1977

           Summary: integral arithmetic operation only on int?
           Product: D
           Version: 2.012
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: someanon@yahoo.com


There's no arithmetic operation for byte? everything has to be cast to int (and
back)?

I try to use the '-w' switch to clear all warnings, but this one isn't necessary:

$ cat bytewarn.d

byte f(byte i) {
  byte t = 1;
  byte o = t - i;
  return o;
}

$ dmd -w -c bytewarn.d
warning - bytewarn.d(4): Error: implicit conversion of expression (cast(int)t -
cast(int)i) of type int to byte can cause loss of data


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1977


smjg@iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg@iname.com
           Keywords|                            |diagnostic




------- Comment #1 from smjg@iname.com  2008-11-20 21:10 -------
It's as documented.  Integral types smaller than int are automagically converted to int when performing arithmetic on them.

But it is somewhat ridiculous that it should still throw the warning in such cases as this.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1977


jarrett.billingsley@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@yahoo.com




------- Comment #2 from jarrett.billingsley@gmail.com  2008-11-21 13:28 -------
*** Bug 2466 has been marked as a duplicate of this bug. ***


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1977





------- Comment #3 from schveiguy@yahoo.com  2008-11-21 13:35 -------
Note that this also errors, and is provably correct.

byte b;
short s = b + b;

IMO, all arithmetic should be allowed on homogeneous operations.  That is, performing arithmetic on two like types should be implicitly assignable to the same type.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1977


andrei@metalanguage.com changed:

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




------- Comment #4 from andrei@metalanguage.com  2008-11-22 06:25 -------
(In reply to comment #1)
> It's as documented.  Integral types smaller than int are automagically converted to int when performing arithmetic on them.
> 
> But it is somewhat ridiculous that it should still throw the warning in such cases as this.

It's not ridiculous at all. The compiler cannot tell what values will be possibly passed to f, and the range of byte and short are sufficiently small to make overflow as frequent as it is confusing and undesirable.

The community has insisted for a long time to tighten integral operations, and now that it's happening, the tightening is reported as a bug :o).


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1977


schveiguy@yahoo.com changed:

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




------- Comment #5 from schveiguy@yahoo.com  2008-11-22 08:44 -------
(In reply to comment #4)
> It's not ridiculous at all. The compiler cannot tell what values will be possibly passed to f, and the range of byte and short are sufficiently small to make overflow as frequent as it is confusing and undesirable.

Why is this also flagged (no overflow possible):

short f(byte i) {
  byte t = 1;
  short o = t - i;
  return o;
}

> The community has insisted for a long time to tighten integral operations, and now that it's happening, the tightening is reported as a bug :o).

But it's pretty inconsistent.  If I add two random ints together, I will get an overflow in 25% of cases, why is that not flagged?

I think the restriction is too tight.  People expect to do math on homogeneous types without having to cast the result, as they do with ints.  And I'll say I was not one of the people asking for this 'feature'.  I'm not sure where that came from.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1977


smjg@iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
            Summary|integral arithmetic         |Relax warnings for implicit
                   |operation only on int?      |narrowing conversions caused
                   |                            |by promotions




------- Comment #6 from smjg@iname.com  2008-11-22 09:01 -------
(In reply to comment #4)
> It's not ridiculous at all.  The compiler cannot tell what values will be possibly passed to f, and the range of byte and short are sufficiently small to make overflow as frequent as it is confusing and undesirable.

I disagree:
- Read comment 3.  How can adding (or even subtracting, multiplying or
dividing) two numbers in the range [-128, 127] possibly produce a value outside
the range [-32768, 32767]?

- If you're using (u)byte/(u)short, it follows that you should know what you're doing.  Especially if you're doing it in an initialiser of something declared explicitly as one of these types, in which case you've shown that you know what you're doing.

- It happens even in the case of bitwise operations (&, |, ^, >>, >>>, but strangely not ~), by which overflow is impossible.  It might be sensible for <<, but no more.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1977





------- Comment #7 from andrei@metalanguage.com  2008-11-22 10:59 -------
(In reply to comment #5)
> (In reply to comment #4)
> > It's not ridiculous at all. The compiler cannot tell what values will be possibly passed to f, and the range of byte and short are sufficiently small to make overflow as frequent as it is confusing and undesirable.
> 
> Why is this also flagged (no overflow possible):
> 
> short f(byte i) {
>   byte t = 1;
>   short o = t - i;
>   return o;
> }

This should go through no problem indeed, I hadn't seen your first reply when I replied.

> > The community has insisted for a long time to tighten integral operations, and now that it's happening, the tightening is reported as a bug :o).
> 
> But it's pretty inconsistent.  If I add two random ints together, I will get an overflow in 25% of cases, why is that not flagged?
> 
> I think the restriction is too tight.  People expect to do math on homogeneous types without having to cast the result, as they do with ints.  And I'll say I was not one of the people asking for this 'feature'.  I'm not sure where that came from.

In general, we want to go with the simple rule is to have an operation return the tightest type that won't engender overflow (which precludes making 8- and 16-bit values as closed sets for addition). The exception to that is int, which for a combination of practical reasons, "stays" int even if it could overflow, and also long, which cannot go any larger. Anecdotal evidence suggests that unintended overflows can be more annoying than having to insert the occasional cast.

We could relax this rule by having the compiler statically tracking possible ranges of values.

The random ints argument does not quite hold because one seldom adds fully random 32-bit values. "Most integers are small."


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1977





------- Comment #8 from andrei@metalanguage.com  2008-11-22 11:04 -------
(In reply to comment #6)
> (In reply to comment #4)
> > It's not ridiculous at all.  The compiler cannot tell what values will be possibly passed to f, and the range of byte and short are sufficiently small to make overflow as frequent as it is confusing and undesirable.
> 
> I disagree:
> - Read comment 3.  How can adding (or even subtracting, multiplying or
> dividing) two numbers in the range [-128, 127] possibly produce a value outside
> the range [-32768, 32767]?

Sorry. Indeed, that is a good reason to keep the bug opened.

> - If you're using (u)byte/(u)short, it follows that you should know what you're doing.  Especially if you're doing it in an initialiser of something declared explicitly as one of these types, in which case you've shown that you know what you're doing.

Often, a 8/16-bit int comes from a need to minimize occupied storage in a larger structure, to conform to some format etc. I do agree that often people operating with such structures/in such environments do know what they're doing, but that doesn't mean that implies they must increase their attention. Knowing what they're doing, they'll insert a cast.

> - It happens even in the case of bitwise operations (&, |, ^, >>, >>>, but strangely not ~), by which overflow is impossible.  It might be sensible for <<, but no more.

The plan is to have sensible bitwise operations preserve the size of their operands. Only arithmetic and shift will "spill" into larger types.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1977





------- Comment #9 from jarrett.billingsley@gmail.com  2008-11-22 11:22 -------
(In reply to comment #8)
> The plan is to have sensible bitwise operations preserve the size of their operands. Only arithmetic and shift will "spill" into larger types.
> 

I hope you mean only *left* shift will spill into a larger type.


--