Zcoin implementation bug enabled attacker to create 548, 000 Zcoins

[XavierAP via Digitalmars-d]

On Sunday, 12 March 2017 at 08:03:46 UTC, Jerry wrote:
> On Tuesday, 7 March 2017 at 21:34:35 UTC, Walter Bright wrote:
>> On 3/7/2017 9:45 AM, Atila Neves wrote:
>>> 1 warning generated.
>>
>> Pretty much all C++ compilers will generate warnings for this. 
>> The thing about warnings, though, is they imply that there are 
>> situations where the code is acceptable. I can't think of any. 
>> It needs to be an error. It should never pass the compiler.
>
> What about Ketmar's example? It seems to have been glossed over.

We've discussed it quite thoroughly...
Again IMO it's not a good idea to require opEquals and others to 
be @pure. Not much of a discussion really since it would be a 
breaking change, besides the opposite of an improvement.

Again the only good possibility I can think if we really really 
want to disallow a==b etc. for custom types, is to add a new 
feature to the specification. This change would also be breaking 
but at least of bad practice only. But how to introduce it is not 
easy: it could be either a new very strange attribute (method may 
have side effects inside the defining type but not outside) too 
similar to pure and const (no thanks) or rather a special case 
for some operators, e.g. a==b statement is never allowed even if 
opEquals isn't pure. The problem is for example that you want to 
do the same for operator "+" but not "++", and both are 
overloaded by opUnary, so the solution is even harder here.

I think my conclusion is leave the thing as it is :)

> Still waiting on D to do something about comparisons between 
> signed and unsigned types, or is having no warning or error the 
> desired behavior?

For me yes it's the desired one.

Implicit casts leading to overflow are a different issue. It 
looks they are never checked even in @safe environments (I know, 
@safe is related to memory, not data corruption). C# has 
checked{} and unchecked{} environments:
https://msdn.microsoft.com/library/khy08726.aspx

But now we're off topic...