Zcoin implementation bug enabled attacker to create 548, 000 Zcoins

[H. S. Teoh via Digitalmars-d]

On Fri, Mar 10, 2017 at 09:07:36PM +0000, XavierAP via Digitalmars-d wrote:
> On Friday, 10 March 2017 at 19:02:06 UTC, H. S. Teoh wrote:
[...]
> > AFAIK Walter's stance is that overloading operators with semantics
> > other than generalizations of arithmetic operators are a bad idea.
> > This is why D uses opCmp for overloading <, <=, ==, >=, >, instead
> > of one overload per operator like C++ has.  Separately overloading <
> > and <=, for example, means that the programmer can do truly weird
> > things with it, which makes code hard to read (when you see "a < b"
> > and "a <= b", you have no idea what they *really* mean).
> 
> * D does not use opCmp for == but I'm sure it slipped your tongue ;)

Haha, you got me there. :-P

But in fact, the very fact that == is handled by opEquals and
inequalities are handled by opCmp has led to some amount of debate some
time ago, because it's possible for them to be inconsistent with each
other.  (Sorry, I'm too lazy to look up the thread right now, but you
can search the forum archives for the (rather lengthy!) discussion.)
This goes to show that overloading individual operators separately from
other related operators can eventually become a source of problems.


> I agree with that stance on style myself, and also with the hard
> restriction to keep the (in)equality and comparison operators
> consistent with each other. But the question is whether to restrict
> programmers further with no other reason than style. D's philosophy is
> maximum @system freedom (just like C/C++) within sanity.
> 
> Also operator overloading style may depend on each engineer's
> background.  Walter's education is mechanical engineering and
> mathematics (coincidentally just like myself), so he dislikes usage of
> operators not analogous to algebra or set theory. Me too; beyond that
> I would rather create methods with self-documenting names.
> 
> But there are software engineers and computer scientists who don't
> care about math, and they may even love iostream's "arrows" indicating
> the direction of the "stream". Leaving aside the specific example of
> iostream, this style discussion is not one where anyone can prove or
> claim to be right. Live and let live.

It's not only about style or math, though.  You may or may not have
encountered lovely C++ snippets like this one:

	int x, y, bitmask;
	cout << x & bitmask << y;	// what do you think this does?
					// vs. what it actually does?

The problem is that "<<" was designed to be a bit-shift operator, and as
such it has a specific precedence level in the hierarchy of operators.
Overloading it to mean something completely unrelated like "output" may
not give it a "sensible" precedence relative to its new meaning. You end
up needing to add parentheses everywhere just to be sure (unless you can
memorize the entire C/C++ operator precedence chart -- I can't).

Operators also have their own associativity according to their intended
semantics; this can make code that abuse operator overloading outside
its intended usage quite unreadable, if the built-in associativity
doesn't match its new meaning.

Basically, operator syntax is just too specific to the arithmetical
meanings of the operators that overloading them to mean something else
seems like just asking for trouble.


T

-- 
The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a. -- Wouter Verhelst