|
|
|
| Authored by: Anonymous on Monday, May 14 2012 @ 12:39 PM EDT |
I think perhaps the OP meant to say "remove and replace with a
non-infringing duplicate function". Which by my understanding they've had
in there for some time anyways.
[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Monday, May 14 2012 @ 12:43 PM EDT |
Yeah, but the code blows up (exceptions are thrown) if range check detects an
error. So, as long as your code doesn't depend on doing the wrong thing to
generate an error, it should work fine.
In fact, array's have a length property which one normally uses in loops and
iterators so that range check is actually a redundant check. It would get
called when you're copying a section of an array -- If that's not failing on a
current system with range check, then removing it should cause no issue (unless
the aforementioned insane coding practice of relying on errors is employed).
We learned our lesson during the 16 bit to 32 bit transition. You don't rely on
the limitations of the system, you explicitly code the intent or you wind up
with unportable code. Though, there are some who never learned the lesson as
evidenced by 32 bit code not running unmodified on 64 bit environments.
Were I Google, I'd try it and see if it crashes when you remove the function --
If it keeps working then there might be a modest speed increase.
rangeCheck's major benefit is to developers when testing their code -- dump a
stack trace on error: oops, I need to fix that; instead of: just happily copying
invalid memory and continuing.[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Monday, May 14 2012 @ 12:54 PM EDT |
some DVM on the device eventually throws some unchecked array exception, makes a
tombstone and goes along to finish booting, or not. That's assuming the
algorithm calling rangeCheck is actually capable of producing an invalid range.
What would be more interesting is to evaluate how many instances of the
two-thousand-odd calls that occur during device boot yield an unfavorable
result.[ Reply to This | Parent | # ]
|
| |
| Authored by: xtifr on Tuesday, May 15 2012 @ 03:57 AM EDT |
The rangeCheck has long since been replaced. They don't have show
any phones. They can just show the new code, say, "look, this isn't
infringing, and serves the same purpose just fine, so just how critical could
that old code have been?"
Oracle seems to be upset that the old version
is still available in the old source code repository. But that's the old
Android! The code's not shipping in any current phones.
---
Do not
meddle in the affairs of Wizards, for it makes them soggy and hard to light. [ Reply to This | Parent | # ]
|
|
|
|
|
