351–360 of 427 posts
Earlier quoted context omitted.
>A lot of shops do this in Java Absolutely not in the memory-safe subset of Java though.
What is the memory-safe subset of Java? Java is memory safe by definition. Sadly, the definition might not give people what they want, which is bug-free code.
Earlier quoted context omitted.
For sure C programs have a runtime. I'm debugging an issue right now that is to do with Windows not shipping VCRUNTIME140_1.DLL on out-of-the-box or old versions of Win10, so in that case it's very clear because you can make C programs that won't start due to a missing runtime library. The runtime isn't all that large but every OS has one. On UNIX it's spread over libc, libpthread, libgcc, libm and so on. On Linux st…
That's a rather idiosyncratic definition of "runtime"
It may feel like C doesn't have a runtime if you're only familiar with UNIX, because the C runtime is guaranteed to come with the OS there whereas other language runtimes are optional and thus more visible. But every language has a runtime.
Earlier quoted context omitted.
High speed fiance is mostly done in Java and Haskell, because mistakes are expensive. (And yeah, it's one of the very few fields that Haskell enters the list.)
Jane Street is all-in on OCaml. Their podcast titled "Signals and Threads" is quite interesting.
Earlier quoted context omitted.
In this case it's not memory unsafe. It is guaranteed to crash the program (or get caught). It's closer to a NullReferenceException than it is to reading from a null pointer in C. There's no memory exploitation you can pull off from this bug being in a Go program, but you could in a C program
It's only guaranteed because of the operating system's sandboxing. > It's closer to a NullReferenceException than it is to reading from a null pointer in C. No, it's exactly the same as a null pointer dereference in C, because it is literally reading from a null pointer in Go as well. In Java, the compiler inserts null checks before every single dereference and throws an exception for null references. > There's no me…
Earlier quoted context omitted.
It's only guaranteed because of the operating system's sandboxing. > It's closer to a NullReferenceException than it is to reading from a null pointer in C. No, it's exactly the same as a null pointer dereference in C, because it is literally reading from a null pointer in Go as well. In Java, the compiler inserts null checks before every single dereference and throws an exception for null references. > There's no me…
> In Java, the compiler inserts null checks before every single dereference and throws an exception for null references. Doesn't OpenJDK install a SIGSEGV handler, and generate the exception from that on a null dereference? (AFAIK, a lot of runtimes for GC'd languages that support thread-based parallelism do so anyway, because they can use mprotect to do a write barrier in hardware.)
I thought I had read that they explicitly don't do that, but I can't find it anymore. You may be right. I should have checked before saying that.
> (AFAIK, a lot of runtimes for GC'd languages that support thread-based parallelism do so anyway, because they can use mprotect to do a write barrier in hardware.)
That's true. I guess those implementations must do something more advanced than "throw a NullPointerException if the program segfaults," given their garbage collector runtimes also rely on that signal.
Can someone explain why we can't double-down on C++ and, through compiler wizardry and reduction in toolset (say, strings can only be fixed-size at 32 chars, 64, or 256 long. No raw pointers, allocator zeroes out all freed memory), achieve a memory-safe language? Obviously, making certain concessions would be a deal-breaker for some, but it might be viable for legacy codebases. If you were to try to make C++ memory-s…
Why you need fixed-size strings? Btw I don’t know how this works in most languages, but circular references can be still a problem even with these restrictions. (If I remember well dangling references can be more or less handled, but correct me if I’m wrong. I remember that JavaScript definitely had problem with those)
Earlier quoted context omitted.
This is a common conception, and I agree to a point. However, interfaces matter. At the interface to _literally any_ system call, unsafe starts to creep out. Either in the wrapper implementation, or in the interface _to_ the system, or even leaking through the wrapper to the caller. At that point, if we have to re-wrap everything in rust to hide the unsafety of the interfaces to the system (sockets, shared mem, etc e…
> At the interface to _literally any_ system call, unsafe starts to creep out. Either in the wrapper implementation, or in the interface _to_ the system, or even leaking through the wrapper to the caller. It’s quite rare to have to make syscalls directly in Rust, just like it is in c++. Most code in any large enough system is related to the internal logic of the system, not to its interface with the outside world. An…
Earlier quoted context omitted.
Really, the only memory unsafe languages still in use are C and C++. If it weren't for the behemoth of legacy code we'd really have this problem more-or-less licked. Unfortunately, that behemoth is still rampaging across the landscape. "Rewrite it in Rust" gets a bit of pushback, perhaps even justified, but at this point in time I'll take anything that just reduces that behemoth in size. The journey of a thousand mil…
Why are C and C++ considered the same, in these conversations? C++ at least has tools to make life significantly more safe. I can write a buffer overflow in any language, and on the scale of difficulty, ASM-C-C++-Rust-Python covers my experience (from easiest to fuck up to hardest). Yet nobody is calling for us to rewrite everything in python. Why is the line drawn at Rust? It's perfectly simple to trash memory in Ru…
Earlier quoted context omitted.
Rust is already most of the way there. The default math operators still do implicit underflow and overflow, but the behavior is actually well defined: debug builds panic on overflow and release builds wrap on overflow. There is no way to get a C-style "demons fly out my nose" overflow. There's also explicit arithmetic functions that let you choose your overflow behavior: * Checked: return None on overflow * Wrapping:…
Do you mean the C compiler's optimization passes can do strange things to code paths that overflow? The last I checked, C would wrap on overflow too. Rust uses the same compiler backend as C, so it could very well have the same behavior emerge from compiler optimization passes.
int would_increment_overflow(int a) {
if (a + 1 0000000000000000 :
0: f3 0f 1e fa endbr64
4: 31 c0 xor %eax,%eax
6: c3 retq