pull down to refresh

I wrote "money stolen". You know, an attack leads to buffer overflow because every C project uses a different string library (CLN's is at ccan/ccan/tal/str/str.c) and if there's a bug in it, an attacker can replace the return address and cause an arbitrary code execution.
By default CLN is less resource hungry than LND, eats less memory.
Of course. Go's GC doubles the memory. A program asks for 1 GB, Go runtime takes 2 GB. That's normal for multithreaded GCs.
Sorry, misread you.
These libs are well tested, small chance to have bugs there, I would bet on bugs at other code. I mean, look at, for example, libc string.h, which I have reimplemented from scratch long time ago - it's simple, hard to introduce bugs there, that's why you use unit tests nowadays. More likely that bugs will be at other places. And buffer overflows aren't the only way how to introduce bugs and get money stolen.
Using Go or Rust has benefits, but it doesn't gurantee bug free code. Actual programmers, who wrote code, are more important.
So, IMO refusing to run software just because language it is written in is stupid. Although I personally am always more careful with JavaScript (node.js) stuff.
Also - fuel injection, ABS, traction control and other low level stuff in almost every car is most likely controlled by software written in C or C++. You will not drive cars because of that?
reply
that's why you use unit tests nowadays
They don't necessarily protect you against an attack.
More likely that bugs will be at other places.
Buffer overflows IIRC are a majority of vulnerabilities. Can't find the stats right now.
And buffer overflows aren't the only way how to introduce bugs and get money stolen.
Definitely.
You will not drive cars because of that?
If all of this is exposed to the internet then yes, maybe I won't.
reply
You will not drive cars because of that?
If all of this is exposed to the internet then yes, maybe I won't.
Buffer overflows with terrible consequences can be caused by any unexpected input data if code doesn't handle that, even without being connected to Internet or bad actor feeding in this data with intent.
P.S. Buffer overflow problem could have been solved by segmented memory architecture of x86 protected mode (put every data structure in different memory segment with specified size, no overflows possible, CPU handles that), unfortunatelly, that didn't get widespread use, because wasn't portable to different CPU architectures and eventually got dropped from x86_64.
reply
It can be, yes, but mostly in the sense that one can win a lottery. It is bad actors that you should beware of.
reply