harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [classLib]Given a long value, RI behaves differently on windows and linux (and TestNG?)
Date Fri, 28 Jul 2006 06:04:10 GMT
But from the bug it follows that SUN result depends on long-to-int
convertion.
So you never know if result if positive (OK) or negative (Exception).
I vote just to do it right and to ignore buggy RI behaviour in this case.

On 7/28/06, Jimmy, Jing Lv <firepure@gmail.com> wrote:
>
> Hi,
>      Thanks, Mikhail :) I read though that bug detail, but I think this
> is not the same thing we are talking about. That bug was caused by a
> long-to-integer-cast, "Integer.MAX_VALUE + 1" is a integer value that is
> less than zero. The evaluation of that bug says:
> "...
>         file.transferFrom(socket, 0, Integer.MAX_VALUE + 1);
> this is not correct, it should be:
>         file.transferFrom(socket, 0, (long)Integer.MAX_VALUE + 1L);
> ..."
> And it throws IllegalArgumentException.
>
> But in our topic, the IOException was caused by native operation. The
> question is, shall we modify native code/Harmony portlib to allow
> system-call deal with the long parameter itself, instead of dealing it
> in Harmony code? RI seems doing in this way.
>
>
-- 
Mikhail Fursov

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message