[e-lang] An attack on a mint
Dean Tribble
tribble at e-dean.com
Mon Mar 10 03:38:45 EDT 2008
> Since there's some measure of social engineering to expressing this
> code such that it will survive maintenance, I'd like to try out a
> version to see how people react:
>
> Suppose a rewrite like:
>
>
> int take(final PurseX src) {
> if (dead) { throw new NullPointerException(); }
> if (src.dead) { throw new NullPointerException(); }
>
> // subtract the credits from the source
>
> final int r = src.balance;
> src.balance = 0;
>
> // add the credits to the destination
> balance += r;
>
> return r;
> }
>
> Is such a layout sufficient to discourage reversion to the previous state?
First, I'd love to see REQUIRE or some such added for "precondition"
non-null checks. That's mostly an aside, though.
I would think it would be better to explicitly articulate the
different case, even though it costs a conditional, as in:
int take(final PurseX src) {
REQUIRE(dead);
REQUIRE(src);
if (src == this) {
// no-op deposit for self
return 0;
} else {
final int r = src.balance;
// for fail-safe, always reduce value or authority first
src.balance = 0;
balance += r;
return r;
}
}
It's an interesting question as to whether in a transfer to self you
return 0 or r, but by making it a separate case you at least are clear
about making that decision.
More information about the e-lang
mailing list