Re: byte + byte -> int



Lew wrote:
Eric Sosman wrote:
This feature of the definition of Java is a little bit
arbitrary, to be sure. For example, in

int x = Integer.MIN_VALUE + 10;
int y = Integer.MIN_VALUE + 20;
int z = x + y;

... the arguments in the preceding paragraph still apply, with
the obvious changes. The compiler doesn't know that x and y are
constant, the compiler can't be sure that their mathematical sum
is in range for an int (in fact, it isn't), but allows the line
anyhow. Java doesn't complain about the loss of precision when

That's because Java doesn't see this as a loss of precision but as an
overflow, and the rules specifically address overflow.

an int (or long) calculation wraps around, but whines loudly when
it thinks precision might be lost in a down-conversion. It's not
consistent, it may not be defensible -- but That's The Way It Is.

It's both consistent and defensible. The operation of integer
addition always results in a 32-bit value, so there's no loss of
precision when you assign the result to an integer.

That's just defining the problem away, not solving it or even
avoiding it. Java adds a couple numbers and delivers an answer,
an answer that would earn a failing mark on a third-grade arithmetic
quiz, and proudly boasts "That's not a bug; that's a feature!" It
crosses my mind that the JLS is akin to Newspeak.

The old steam-powered computers I shovelled coal for as a lad[*]
had one nice feature that our sleek fast modern machines have lost:
They'd trap when a computation overflowed. Blasted inconvenient now
and then, but a great safety feature for programs that would otherwise
have produced results that were wrong, R-O-N-G, wrong.

[*] "Merely corroborative detail intended to lend verisimilitude
to an otherwise bald and unconvincing narrative." I never actually
shovelled coal into computers; the boilers were gas-fired.

--
Eric.Sosman@xxxxxxx
.



Relevant Pages

  • Re: size_t overflow
    ... than overflow. ... question is about size_t arithmetics. ... means all computations involving unsigned char promoted to int, ... After promotion to int, ...
    (comp.std.c)
  • Re: dynamic vs. static: the age-old debate
    ... int addx+y; ... orthogonal to static/dynamic/soft typing. ... $ dynamic-compiler program.source -o program ... will overflow, leaving the "overflow behavior is ...
    (comp.lang.misc)
  • Re: size_t overflow
    ... than overflow. ... question is about size_t arithmetics. ... ..."A computation involving unsigned operands can never overflow, ... means all computations involving unsigned char promoted to int, ...
    (comp.std.c)
  • ishopcart cgi 0day and multiple vulnerabilities
    ... While spending a night auditing I have found 2 buffer overflows and 1 ... there is an overflow in the vGetPostfunction, it does not do any size checking on the inputed data but instead ... void changeport(char *code, int port, int offset); ...
    (Bugtraq)
  • Re: 12 hour clock and offset problem
    ... not violate precision in time based on precise longitude location. ... even more complex if adjustment is made including seconds. ... is lessened by use of the int() function within perl core. ...
    (comp.lang.perl.misc)