151–160 of 223 posts
I always wonder how these "five conditions ANDed together in an if" make it past code review in general (i know thats not where the actual bug was). I don't care how brilliant a programmer you are, but mistakes in those are very difficult to grasp.
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…
Earlier quoted context omitted.
You can rightfully blame having state setting be part of your language. It is easier to program without state than with it, just like it's easier to juggle 2 balls than 3. Without state (or with the absolutely minimum of it) you can not make mistakes with it. Also, if your state-setting operator is super similar to your equality-checking operator, you can fall into this trap (like the devs in question did). Programmi…
Picking up Clojure and learning to be extremely judicious about the use of persistent state reduced my bug output rate dramatically.
Earlier quoted context omitted.
Yes it is. Assignment is another word for writing state. If your programming environment doesn't include a way to set state, you will never do it. Why is doing the dangerous task of writing state so easy you just have to hit one key to do it in C++? Let's collectively put our seat belts on, colleagues!
The bug here was a lack of writing state!
If there was not state, the coder wouldn't had tried to set it. I don't think a language needs to have the `=` operator easy and close at hand. Had that not been the case, this bug (and oh so many others) would never had existed.
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…
HN's law: all problems with C can be solved by writing a sufficiently high-brow post containing snide observations only a sophomore is smart enough to come up with..
Isn't it true though, that with some techniques certain bugs are impossible to make? If you have not experienced it, I recommend you to seek it out and try.
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…
It's an absurd point. ZCash was built upon the Bitcoin codebase. This inherits a lot of bad decisions. Moral purity, demanding they start over again from scratch, just isn't practical. The bug in question could have been solved had the simply compiled with minimal static analysis -- by which I mean -Wall. C/C++ is memory safe if you turn on dynamic checking. Sure, it's twice as slow as C/C++, but still tons faster th…
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…
The problem isn't in the implementation, it's a problem with Zcoin itself. One should not be able to create Zcoin via software whether that's a bug or deliberate.
Earlier quoted context omitted.
I want to agree with you but in practice I can't really imagine switching -Werror outside of dev builds. The problem is that different compilers have different warnings and if your code is meant to be portable it's going to be a serious pain to avoid all the warnings all the time. Having compilation break for a user because of a spurious warning due to a different compiler (or different compiler version) would make i…
warning: comparison is always true due to limited range of data type Surely this is a serious problem on 16 bit builds; the comparison implies that larger values are expected to be stored in this variable, the warning is a strong hint that the (size of the) types are incorrect.
Earlier quoted context omitted.
This bug had nothing to do with c++ and its ergonomics, let alone it's safety. > Unfortunately when populating the denomination member variable, an equality operator was used instead of assignment, resulting in the denomination always being zero, as set in the class constructor. So = Vs ==
Yes it is. Assignment is another word for writing state. If your programming environment doesn't include a way to set state, you will never do it. Why is doing the dangerous task of writing state so easy you just have to hit one key to do it in C++? Let's collectively put our seat belts on, colleagues!
Earlier quoted context omitted.
Well, crypto/bitcoin businesses in general tend to be quite lucrative. However lots of risks as well. For a security researcher there are no downside risks as much.
> crypto/bitcoin businesses in general tend to be quite lucrative. That's called a pyramid, or ponzi scheme.