It's not like Java is immune to memory safety-related implementation bugs either (e.g., [0]):

> A resource area allocated object is probably passed/used outside of the scope of the corresponding ResourceMark (similar to JDK-8325672).

So "blows Rust away in memory safety" doesn't seem quite supported enough?

[0]: https://bugs.openjdk.org/browse/JDK-8336095

You don't need 'static to trigger the bug [0]

[0]: https://github.com/rust-lang/rust/issues/164250#issuecomment...

This bug wouldn't be nearly as interesting if it "just" resulted in a memory leak. Memory leaks aren't considered unsafe in Rust because they can't result in UB in the same way as e.g., OOB writes. In fact, there are APIs accessible in safe Rust which explicitly leak memory! [0]

This bug is effectively a use-after-free, which is definitely something that the Rust compiler should catch.

> Would be cool to see clippy pick up on this bug in older versions!

No need for that. A future version of the Rust compiler that incorporates a fix should reject the incorrect code, so all you'd need to do is compile older code with that new compiler.

[0]: https://doc.rust-lang.org/std/mem/fn.forget.html

The difference is that the C spec intentionally frees the compiler from upholding those invariants. In this case the Rust compiler is failing to catch something it is required to catch.

A more accurate analogy would be a C compiler incorrectly failing to reject an assignment through a pointer to const without a cast. The spec requires that such a thing be rejected, so it's a compiler bug.

Bit of a (not so?) fun fact: char* being a universal alias can lead to some potentially unexpected slowdowns [0], especially if the char* bit is behind a typedef.

[0]: https://travisdowns.github.io/blog/2019/08/26/vector-inc.htm...

Yes, but in C standardese a "byte" is not necessarily the 8 bits that it's normally thought to be these days. From C89 Section 2.2.4.2 Numerical Limits [-1]:

> maximum number of bits for smallest object that is not a bit-field (byte) CHAR_BIT 8

i.e., CHAR_BIT is the number of bits in a byte. C23 has a similar definition, and further defines CHAR_WIDTH that is defined to expand to the same value as CHAR_BIT.

> So I don't believe your statement "sizeof(char) is guaranteed to always be 1" is correct.

From C89 section 3.3.3.4 The sizeof operator [0]:

> When applied to an operand that has type char, unsigned char, or signed char, (or a qualified version thereof) the result is 1.

This wording remains basically identical through C23 [1].

> Where does the spec say that a char* can be used to address any point in an object?

From C89 section 3.3 Expressions:

> An object shall have its stored value accessed only by an lvalue that has one of the following types:

>

> * a character type.

This also remains the case up through C23.

I think you're thinking of the strict aliasing rule with your example, but character types are one of the exceptions to said rule so I think your example is actually fully defined. It'd be UB if you casted to an incompatible type like a float, I believe.

[-1]: https://port70.net/%7Ensz/c/c89/c89-draft.html#2.2.4.2

[0]: https://port70.net/%7Ensz/c/c89/c89-draft.html#3.3.3.4

[1]: https://port70.net/%7Ensz/c/c23/n3220.html#6.5.4.4

[2]: https://port70.net/%7Ensz/c/c89/c89-draft.html#3.3

[3]: https://port70.net/%7Ensz/c/c23/n3220.html#6.5.1

And you never will, since sizeof(char) is guaranteed to always be 1.

I'm guessing you were thinking of CHAR_BIT != 8, but even then I'm not sure it would make a difference since malloc takes its argument size in bytes and a char more or less is a byte in C.

(Consider that char*s are also how you access the byte-level representation of objects in C. If chars were not the minimum addressable unit then that use wouldn't work)

For what it's worth, in that specific instance there's no memory safety issue since Rust is guaranteed to crash on stack overflow on Ubuntu (and probably other supported Linux distros)

That being said, one of the Rust devs indicated in the corresponding lobste.rs discussion [2] that they're open to revisiting/rebalancing things if they get enough bug reports indicating something is up, so it might not hurt to tag onto the bug report the author will (hopefully) eventually submit.

[0]: https://github.com/rust-lang/rust/pull/117727

[1]: https://github.com/rust-lang/rust/pull/118031

[2]: https://lobste.rs/s/dldhpw/rust_s_derive_often_implies_inlin...

Comments URL: https://news.ycombinator.com/item?id=49953344

Points: 77

# Comments: 28

> The picture given looks like Minecraft.

That is because you're looking at the picture now, after it has been fixed.

[0]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p27...

[1]: https://herbsutter.com/2025/11/10/trip-report-november-2025-...

I mean, sure, insofar as such a thing would also imply that a) the standard would need quite a bit of cleanup/clarification work to not contradict your definition, and b) the main optimizing C++ compilers are miscompiling code, analogous to how cve-rs is a rustc miscompilation rather than an issue with Rust itself.

(Fil-C might be an interesting exception here, though IIRC its definition of memory safety is slightly different)

I suppose it depends on who is doing the classifying? From the developer's standpoint I'd imagine intent is all that matters: a bug is something that does not match developer intent and that is (eventually) expected to be changed to match the intent, while a feature is something that does match developer intent regardless of how old/new it is. From a user's standpoint I'd imagine it's a combination of developer intent and the user's reliance on said behavior, but IIRC in this particular case there's no known non-demo code that has organically run into this particular bug so there's little weight in favor of calling the bug a feature despite the devs' stance.

Also as GP said I think one needs to be careful to distinguish between the compiler and the language. IIRC the devs have known for basically this entire time exactly in what manner the Rust compiler fail to implement the rules of Rust the language, but a general fix has been blocked on long-running projects that have only recently been approaching the finish line [1].

[0]: https://news.ycombinator.com/item?id=40431444

[1]: https://blog.rust-lang.org/2026/08/21/enabling-next-solver-o...