121–130 of 223 posts
Earlier quoted context omitted.
> C/C++ is memory safe if you turn on dynamic checking. Is anyone here doing this? Would be interesting to hear your experience.
If valgrind counts, then yes.
valgrind --quiet --leak-check=full --error-exitcode=1 *binary*Earlier quoted context omitted.
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…
Ada has multiple implementations, is pretty safe, and produces fast code. Yet it isn't popular, so I guess there are other factors that are more important than number of compilers and speed.
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.
As a c++ developer I would nope the hell out of there or spend a month fixing the warnings - depending on pay. No way would I work with something in that state long term.
> until somebody gets to fix all warnings which are not bugs.
Code that is filled with ignored warnings generally gets worse, not better. Having little to no quality standards does that.
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.
--
[0] - even if by ignoring them, when you're absolutely sure what you're doing.
Earlier quoted context omitted.
The commit that fixes it does not change any tests: https://github.com/zcoinofficial/zcoin/commit/0359bcb2ead7fe... This indicates that the code in question is not covered by tests. I work on a database, for which correctness is paramount, so it's unnerving to see any code fixes not associated with test additions or changes. I would have thought that cryptocurrency had similar standards.
I think that won't even compile due to an accidentally pasted URL here: https://github.com/zcoinofficial/zcoin/commit/0359bcb2ead7fe...
Earlier quoted context omitted.
Do you think this is immoral? I am genuinely curious as to what the arguments would be one way or another. People are taking a risk with these things and they know they're risky. So it's not really stealing.
I believe it is a crime, both in spirit and on paper. In spirit, you took something that was not yours and not meant for you, and by selling the coins you decreased the value of everyone else's. On paper, let's say that the developers behind whatever coin you hack decide that they are going to take no action. You still run afoul of countless computer security laws designed, however poorly, to protect people from hack…
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.
Easy. Either there is no code review, the code review is done by someone who has far too much on his plate a works on the theory that as long as it compiles and runs it's probably fine or the code review is done by someone likes writing code with five conditions ANDed together in an if and thinks it's fine
Earlier quoted context omitted.
If there are vulnerabilities, those vulnerabilities will be exploited. That will reduce the currency value and the value of their 'founders reward'
Not if they cash out during "IPO." I don't like the idea of a founder/developer pool, but if they are going to have one, there should be a vesting period, such that the granted coins cannot be moved for X years after receiving them. This will keep the incentive alive, and I think Ethereum would have a lot more potential if something like this was employed.
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…
I think the lesser amount of libraries and lacking the chance of fine-tuning performance (but also your risk of screwing up your performance badly) is a very low price for the provably impossibility to have a mistake like this.
I'm just thinking back on my career, which has been full of bugs of all magnitudes. If I categorise my past bugs, there are many common patterns. Famous old-timers have names, like buffer overflows or memory leaks etc etc. Just not having the possibility to make those errors is such a freeing experience.
Also what's the big problem with no independent standardisation?
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…
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 ==
Let's collectively put our seat belts on, colleagues!