281–290 of 427 posts
Earlier quoted context omitted.
How to quit vim.
long-press power button
Given the vast amount of C/C++ around, much which will never be rewritten, I wonder if bounds checking compilers should be considered?
Earlier quoted context omitted.
> It's perfectly simple to trash memory in Rust. What makes you think so? Most Rust programmers and programmers from other languages, agree that this is not possible. I might be missing something, but can you give an example of such simple methods to trash memory in Rust, asking from a curiosity standpoint?
I don’t think most Rust programmers agree it’s impossible at all. There’s always unsafe. I can make a pointer to anywhere by hand and write to it. That would involve some very intentional work, but I could do it if I wanted to.
I advise training programmers instead of throwing them in front of a screen without any training. Companies these days provides no training at all. When I was hired over 40 years ago, I spent plenty of time being trained for my first 3 months. Now, nothing, and you if you want to train a new person, you do it on your own time.
Even in highly regulated, controlled environments memory safety is still an issue. I have seen bugs in these environments where I know for a fact that the developer has had 40-80 hours of training on memory safety and they still pop up.
If these people have occasional issues, the rest of the world has no effin chance.
Their "Appendix: Memory Safe Languages" lists: C#, Go, Java, Python, Rust & Swift
Why is Python listed there and not other languages like Ruby, Javascript or Perl?
I advise training programmers instead of throwing them in front of a screen without any training. Companies these days provides no training at all. When I was hired over 40 years ago, I spent plenty of time being trained for my first 3 months. Now, nothing, and you if you want to train a new person, you do it on your own time.
Earlier quoted context omitted.
Go is memory safe, that post does not means anything in real life scenario. Do you have a single example in the last 14 years of memory safety exploit using the Go runtime? I'm talking about public and known exploit not ctf and the like.
The same author has a post from 2022 [1]. > Is it possible to achieve arbitrary code execution on any Go version, even with PIE, and with no package import at all, just builtins? Yes! Whether it's capture the flag is irrelevant, IMO, because anything that's allowed by the compiler will emerge given enough complexity. 1: https://blog.stalkr.net/2022/01/universal-go-exploit-using-d...
I mean if in 14 years there was nothing it's a proof that it's not an issue.
Even the attacker ack that it's not a threat.
"As said before, while a fun exercise it's pretty useless in the current Go threat mode"
Earlier quoted context omitted.
> absolutely correct, in fact now some new hires are expected to do a few git-commit the first day(looking at you, Meta). Meta have a phenomenally good training program, called Bootcamp for basically everyone in engineering, so they're probably not the example you're looking for.
I recall meta expects new hires to do first commit the first day, not sure how its training will help in this scenario, this is in no way saying meta has no good training, it just does not add up here though.
Unless it is a “hello world” commit to confirm tooling is operational, I have strong doubts.
How about a new drop-in replacement language for c/c++? I'm in no way an expert in any aspect that relates to this problem, but it's reasonable to believe that it would be but a mildly challenging task if companies like Google, meta, Microsoft and the likes joined forces. A year of concentrated efforts might be sufficient to rid us with this problem once and for all. Billions of lines of codes would gain (some) safet…
You can't do "drop-in replacement" and "memory safety" at the same time.