Zcoin implementation bug enabled attacker to create over 500K Zcoins

Post by adrianN » Tue, Mar 07, 2017, 9:48 AM UTC

Sanddancer wrote: post #95

yjgyhj wrote: post #71

The point I'm about to make in this comment is so old and has been said so many times that we all are tired of hearing it. But why do we use a language like C++ to implement something where we don't wish to have bugs? C++ is not memory-safe (no GC or whatever Rust does), it's not type safe (in the ML sense), it relies on writing to memory a lot (instead of having pure functions). Had this program been written in Ocam…

Because pretty much any language that's been touted as a replacement has problems which need solved before they'd really be viable. They're either single vendor with no independent standardization, like Rust or D, or have lower performance like go, or both. Once both problems are fixed, it'll be a lot easier to start looking at alternatives. Until then, there's not a language that settles into a lot of the niches C a…

Post by ifdefdebug » Tue, Mar 07, 2017, 9:55 AM UTC

zuzun wrote: post #100

yjgyhj wrote: post #71

The point I'm about to make in this comment is so old and has been said so many times that we all are tired of hearing it. But why do we use a language like C++ to implement something where we don't wish to have bugs? C++ is not memory-safe (no GC or whatever Rust does), it's not type safe (in the ML sense), it relies on writing to memory a lot (instead of having pure functions). Had this program been written in Ocam…

You are looking at a 1k LOC function in a 7k LOC file with a bug that can be easily spotted by -Wall and you think it's the fault of the programming language? The only thing irresponsible is putting your hard-earned money into the 100th Bitcoin fork maintained by some guy with an Anime avatar. Once you stop trusting the developers it essentially becomes an underhanded ... contest and no language wins.

Post by diamondo25 » Tue, Mar 07, 2017, 10:08 AM UTC

ifdefdebug wrote: post #113

zuzun wrote: post #100

Earlier quoted context omitted.

You are looking at a 1k LOC function in a 7k LOC file with a bug that can be easily spotted by -Wall and you think it's the fault of the programming language? The only thing irresponsible is putting your hard-earned money into the 100th Bitcoin fork maintained by some guy with an Anime avatar. Once you stop trusting the developers it essentially becomes an underhanded ... contest and no language wins.

Didn't try, but I could imagine that running -Wall over that codebase produces huge amounts of noise rendering it practically useless, until somebody gets to fix all warnings which are not bugs.

Post by dagw » Tue, Mar 07, 2017, 10:16 AM UTC

WalterBright wrote: post #59

jacquesm wrote: post #52

Earlier quoted context omitted.

You're absolutely right (to my surprise), it gives: test.cpp: In function ‘int main()’: test.cpp:13:11: warning: statement has no effect [-Wunused-value] a == b; ^ But only after enabling a warning that is not on by default. -Wall and -Werror should be the default.

It should be an error, not a warning (default or not). There are a number of things like this that should just not be accepted anymore. Here's another one: if (condition); dothis(); No compiler should accept that, regardless of switch settings.

Post by akvadrako » Tue, Mar 07, 2017, 10:25 AM UTC

ifdefdebug wrote: post #113

zuzun wrote: post #100

Earlier quoted context omitted.

You are looking at a 1k LOC function in a 7k LOC file with a bug that can be easily spotted by -Wall and you think it's the fault of the programming language? The only thing irresponsible is putting your hard-earned money into the 100th Bitcoin fork maintained by some guy with an Anime avatar. Once you stop trusting the developers it essentially becomes an underhanded ... contest and no language wins.

Didn't try, but I could imagine that running -Wall over that codebase produces huge amounts of noise rendering it practically useless, until somebody gets to fix all warnings which are not bugs.