[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