Thread overview | ||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
March 06, 2017 Zcoin implementation bug enabled attacker to create 548,000 Zcoins | ||||
---|---|---|---|---|
| ||||
https://makebitcoingreatagain.wordpress.com/2017/02/18/is-the-zcoin-bug-in-checktransaction/#update6 The error is here: https://github.com/zcoinofficial/zcoin/blob/81a667867b5d8489... and the line of code: zccoinSpend.denomination == libzerocoin::ZQ_LOVELACE; In other words, a statement with no effect. In D, such a line gives an error, not a warning: Error: == has no effect in expression |
March 07, 2017 Re: Zcoin implementation bug enabled attacker to create 548,000 Zcoins | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Tuesday, 7 March 2017 at 05:44:49 UTC, Walter Bright wrote:
> https://makebitcoingreatagain.wordpress.com/2017/02/18/is-the-zcoin-bug-in-checktransaction/#update6
>
> The error is here:
>
> https://github.com/zcoinofficial/zcoin/blob/81a667867b5d8489...
>
> and the line of code:
>
> zccoinSpend.denomination == libzerocoin::ZQ_LOVELACE;
>
> In other words, a statement with no effect. In D, such a line gives an error, not a warning:
>
> Error: == has no effect in expression
To be fair, this also would have been caught with proper testing ... which obviously didn't happen.
OT from D:
Run screaming in the other direction of this shit. For this to pass through I wouldn't trust these devs with $10, let alone any of my financial security. I still have trust issues with coinbase, let alone some fly-by-night custom bitcoin derivative.
|
March 06, 2017 Re: Zcoin implementation bug enabled attacker to create 548,000 Zcoins | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jack Stouffer | On 3/6/2017 10:06 PM, Jack Stouffer wrote:
> To be fair, this also would have been caught with proper testing ... which
> obviously didn't happen.
My idea of fair is it should never have gotten past the compiler. It's a simple mistake for the compiler to detect.
|
March 07, 2017 Re: Zcoin implementation bug enabled attacker to create 548,000 Zcoins | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | Walter Bright wrote:
> https://makebitcoingreatagain.wordpress.com/2017/02/18/is-the-zcoin-bug-in-checktransaction/#update6
>
> The error is here:
>
> https://github.com/zcoinofficial/zcoin/blob/81a667867b5d8489...
>
> and the line of code:
>
> zccoinSpend.denomination == libzerocoin::ZQ_LOVELACE;
>
> In other words, a statement with no effect. In D, such a line gives an error, not a warning:
>
> Error: == has no effect in expression
only for primitive types, sadly.
void main () {
Object a, b;
a == b;
}
oops. no more error messages. yes, i know that this invokes `opEquals()`, and `opEquals()` can have side-effects. but what are the chances of writing such code *intentionally*?
i guess, compiler should emit error for *any* usage of "==" without using the result, even if it lowers to `opEquals()` or something. and if one really want to use it and drop it's result, there is always escape path:
cast(void)(a == b);
|
March 07, 2017 Re: Zcoin implementation bug enabled attacker to create 548,000 Zcoins | ||||
---|---|---|---|---|
| ||||
Posted in reply to ketmar | On Tuesday, 7 March 2017 at 15:05:45 UTC, ketmar wrote: > only for primitive types, sadly. > > void main () { > Object a, b; > a == b; > } > > oops. no more error messages. yes, i know that this invokes `opEquals()`, and `opEquals()` can have side-effects. but what are the chances of writing such code *intentionally*? Hmm, I guess the compiler can (and should) output an error message if it knows that opEquals is `pure`. https://issues.dlang.org/show_bug.cgi?id=17245 |
March 07, 2017 Re: Zcoin implementation bug enabled attacker to create 548,000 Zcoins | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jack Stouffer | Jack Stouffer wrote:
> On Tuesday, 7 March 2017 at 15:05:45 UTC, ketmar wrote:
>> only for primitive types, sadly.
>>
>> void main () {
>> Object a, b;
>> a == b;
>> }
>>
>> oops. no more error messages. yes, i know that this invokes `opEquals()`, and `opEquals()` can have side-effects. but what are the chances of writing such code *intentionally*?
>
> Hmm, I guess the compiler can (and should) output an error message if it knows that opEquals is `pure`.
>
> https://issues.dlang.org/show_bug.cgi?id=17245
yet Object's `opEquals()` is not pure (and it cannot be, to allow non-pure overloads). still, the code i've written has no sense.
|
March 07, 2017 Re: Zcoin implementation bug enabled attacker to create 548,000 Zcoins | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Tuesday, 7 March 2017 at 06:59:38 UTC, Walter Bright wrote:
> On 3/6/2017 10:06 PM, Jack Stouffer wrote:
>> To be fair, this also would have been caught with proper testing ... which
>> obviously didn't happen.
>
> My idea of fair is it should never have gotten past the compiler. It's a simple mistake for the compiler to detect.
clang 3.9.1 with 0 flags used:
$ cat zcoin.cpp
int main() {
int a, b;
a == b;
}
$ clang++ zcoin.cpp
zcoin.cpp:3:7: warning: equality comparison result unused [-Wunused-comparison]
a == b;
~~^~~~
zcoin.cpp:3:7: note: use '=' to turn this equality comparison into an assignment
a == b;
^~
=
1 warning generated.
gcc, sadly, warns about nothing by default but does with `-Wall`. But... anyone not using `-Wall -Wextra -Werror` on a new C++ codebase shouldn't be writing C++ AFAIC*. And then there's the aforementioned lack of adequate testing.
Does D do better? Sort of (clang issues a warning, which I know can be and is often ignored). Is this an example of amateur hour by the Zcoin devs? Indubitably.
Atila
* Maybe there should be something like a driver's license for C++ where devs have to pass a test before they're allowed to write code. Something like "Do you know how to use std::enable_if without looking at cppreference.com? No? Fail." (I'd fail, I _always_ have to look up how to use enable_if. Then again, it _is_ a horrible hacky hack of a hack based on the hack that is SNIFAE).
|
March 07, 2017 Re: Zcoin implementation bug enabled attacker to create 548,000 Zcoins | ||||
---|---|---|---|---|
| ||||
Posted in reply to Atila Neves | 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. > Does D do better? Yes, it's an error in D. |
March 09, 2017 Re: Zcoin implementation bug enabled attacker to create 548,000 Zcoins | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Tuesday, 7 March 2017 at 05:44:49 UTC, Walter Bright wrote: > https://makebitcoingreatagain.wordpress.com/2017/02/18/is-the-zcoin-bug-in-checktransaction/#update6 > > The error is here: > > https://github.com/zcoinofficial/zcoin/blob/81a667867b5d8489... > > and the line of code: > > zccoinSpend.denomination == libzerocoin::ZQ_LOVELACE; > > In other words, a statement with no effect. In D, such a line gives an error, not a warning: > > Error: == has no effect in expression Coincidentally, saw this in https://www.youtube.com/watch?v=A8Btr8TPJ8c&feature=youtu.be&t=469, while watching DConf 2015. No one spotted this bug (wasFound) in the conf? |
March 09, 2017 Re: Zcoin implementation bug enabled attacker to create 548,000 Zcoins | ||||
---|---|---|---|---|
| ||||
Posted in reply to Atila Neves | On Tuesday, 7 March 2017 at 17:45:13 UTC, Atila Neves wrote:
> write code. Something like "Do you know how to use std::enable_if without looking at cppreference.com? No? Fail." (I'd fail, I _always_ have to look up how to use enable_if. Then again, it _is_ a horrible hacky hack of a hack based on the hack that is SNIFAE).
"std::enable_if" is a hack, but I don't think the underlying principle of SFINAE is a hack as such, although it isn't principled in C++... SFINAE basically allows deduction and pattern matching at some level, which is what turned it into a useful programming mechanism. And those can be desirable features.
Of course the syntax isn't great for the casual reader, e.g.:
"template<T, typename std:enable_if_t<T == MyType, int> == 0> ..."
But the crux to making C++ code readable is to use a smaller set of general formulations, make those idioms and avoid all the alternative ways that are less general.
void_t is kinda neat:
"template<typename T, typename = void_t<>>struct mystuff ..."
"template<typename T> struct mystuff<T, void_t<A> > ..."
"template<typename T> struct mystuff<T, void_t<B> > ..."
|
Copyright © 1999-2021 by the D Language Foundation