Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A deep dive into Rust and C memory interoperability

notashes.me

Post reply on HN
Print view View original

41–50 of 84 posts

Re: A deep dive into Rust and C memory interoperability

#41

Post by CupricTea »

veber-alex wrote: post #14

The reason you are not seeing crashes when allocating with Rust and freeing with C (or vice versa) is that by default Rust also uses the libc allocator. https://stdrs.dev/nightly/x86_64-unknown-linux-gnu/src/std/s...

It's funny. When I first tried Rust in 2018 they were still statically linking jemalloc into every binary rustc compiled by default, and that alone very much put me off of the language for a while.

Apparently they did away with jemalloc in favor of the system allocator that same year but nonetheless when I came back to it years later I was very happy to learn of its removal.

Re: A deep dive into Rust and C memory interoperability

#43

Post by School-Cotton »

CupricTea wrote: post #41
veber-alex wrote: post #14

The reason you are not seeing crashes when allocating with Rust and freeing with C (or vice versa) is that by default Rust also uses the libc allocator. https://stdrs.dev/nightly/x86_64-unknown-linux-gnu/src/std/s...

It's funny. When I first tried Rust in 2018 they were still statically linking jemalloc into every binary rustc compiled by default, and that alone very much put me off of the language for a while. Apparently they did away with jemalloc in favor of the system allocator that same year but nonetheless when I came back to it years later I was very happy to learn of its removal.

> that alone very much put me off of the language for a while

Why?

Re: A deep dive into Rust and C memory interoperability

#45

Post by broken_broken_ »

phkahler wrote: post #3

Something I'd like to know for mixing Rust and C. I know it's possible to access a struct from both C and Rust code and have seen examples. But those all use accessor functions on the Rust side rather than accessing the members directly. Is it possible to define a structure in one of the languages and then via some wrapper or definitions be able to access it idiomatically in the other language? Can you point to some…

I wrote a blog article about exactly this, using a C++ class from C++, C and Rust: https://gaultier.github.io/blog/rust_c++_interop_trick.html

Re: A deep dive into Rust and C memory interoperability

#46

Post by ainiriand »

CupricTea wrote: post #41
veber-alex wrote: post #14

The reason you are not seeing crashes when allocating with Rust and freeing with C (or vice versa) is that by default Rust also uses the libc allocator. https://stdrs.dev/nightly/x86_64-unknown-linux-gnu/src/std/s...

It's funny. When I first tried Rust in 2018 they were still statically linking jemalloc into every binary rustc compiled by default, and that alone very much put me off of the language for a while. Apparently they did away with jemalloc in favor of the system allocator that same year but nonetheless when I came back to it years later I was very happy to learn of its removal.

Sorry, but why that can be a downside in 2018?

Re: A deep dive into Rust and C memory interoperability

#47

Post by jml7c5 »

rectang wrote: post #26
ryanf wrote: post #12

This article looked interesting, but I bounced off it because the author appears to have made heavy use of an LLM to generate the text. How can I trust that the content is worth reading if a person didn't care enough to write it themselves?

I find it hard to believe that an LLM would have come up with this quote to start the article: > “Memory oppresses me.” - Severian, The Book of the New Sun That sort of artistic/humourous flourish isn't in character for an LLM.

It looks like a mix of LLM and human-written content. The (human) author would have been the one who chose to put that quote there.

Re: A deep dive into Rust and C memory interoperability

#48

Post by jeroenhd »

PoignardAzur wrote: post #44
sesm wrote: post #2

Section named "The Interview Question That Started Everything" doesn't contain the interview question.

It is, but yeah, the entire article's formatting is pretty weird.

The entire blog post feels formatted like AI output to me. Repeated checklists with restated points, tables and full blocks of code spread across the page in a very specific way.

I don't know if the author used AI to write this, but if they didn't, this is the person AI agents decided to copy the writing style of.

Edit: Reddit thread somewhere in the comments here to a post from the author pretty much confirmed my suspicions, this article is heavily AI generated and plain wrong in several cases. A good reminder not to use AI slop to learn new topics, because LLMs bullshit half the time and you need to know what you're doing to spot the lies.

Re: A deep dive into Rust and C memory interoperability

#49

Post by broken_broken_ »

veber-alex wrote: post #14

The reason you are not seeing crashes when allocating with Rust and freeing with C (or vice versa) is that by default Rust also uses the libc allocator. https://stdrs.dev/nightly/x86_64-unknown-linux-gnu/src/std/s...

Miri and Valgrind will usually catch this kind of issue. I did lots of work mixing C and Rust and that tripped me as well at the beginning. I wrote about it if someone is interested: https://gaultier.github.io/blog/perhaps_rust_needs_defer.htm...

Re: A deep dive into Rust and C memory interoperability

#50

Post by CupricTea »

School-Cotton wrote: post #43
CupricTea wrote: post #41

Earlier quoted context omitted.

It's funny. When I first tried Rust in 2018 they were still statically linking jemalloc into every binary rustc compiled by default, and that alone very much put me off of the language for a while. Apparently they did away with jemalloc in favor of the system allocator that same year but nonetheless when I came back to it years later I was very happy to learn of its removal.

> that alone very much put me off of the language for a while Why?

Jemalloc added over a megabyte to every project for only questionable gains, and it was awkward and unwieldy to remove it. While there are good reasons to use a different allocator depending on the project, Rust defaulting to this type of behavior failed a certain personal litmus test on what it wanted to be as a language in that it felt like it was fighting the system rather than integrating with it.

It also does not give a good first impression at all to newcomers to see their hello world project built in release mode take up almost 2MiB of space. Today it's a much more (subjectively) tolerable 136kiB on Windows (considering that Rust std is statically linked).

Post reply on HN