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

Rust for Filesystems

lwn.net

Post reply on HN
Print view View original

181–190 of 206 posts

Re: Rust for Filesystems

#181

Post by aoieu »

logicprog wrote: post #179
aoieu wrote: post #133

Earlier quoted context omitted.

That sounds highly unlikely given the strict moderation on this site. So unless I see any evidence of it, I'll continue to assume otherwise. From what I can gather after looking at previous posts on Asahi Linux, as another commenter suggested, the author of that message is furious that some HN users were talking about a cartoon character alter ego that he uses to make video streams. Seems to me like he's overreacting…

The letter Martin wrote literally explains why you wouldn't be able to see such comment threads, as a result of the way HN's moderation works. Did you bother to read it? Also, don't even start with the whole "Asahi Lina = Hector Martin" thing. You're literally echoing a Kiwi Farms thing and wondering why people accuse HN of having an overlap with that site?

I browsed the comments of previous Asahi Linux posts with "show dead" switched on and that's all I could find. I couldn't care less if he presents himself as a cartoon character on his video streams, I only mention it because that's what the flagged comments on those posts were arguing about.

Perhaps you could link the comment threads that you believe is evidence of what he's saying in that message?

Re: Rust for Filesystems

#182

Post by kelnos »

mjburgess wrote: post #76
pjc50 wrote: post #51

Earlier quoted context omitted.

The scale of C adoption is certainly unparalleled over the past 40 or so years, but so are the safety issues in the cyberwarfare era. https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/pre... If, somehow, we'd got to an era where (a) operating systems were widely deployed in a different language, and (b) the Morris Worm of 1988 had happened due to buffer overflow issues, then C in its current form would never h…

C is just convenient assembly. In an era where performance mattered, and much software was written for hardware, and controlling hardware, it's hard to see an alternative. C's choices were for performance on hardware-limited systems. I don't really see what other ones made sense historically.

> C is just convenient assembly.

I'm not sure if you're being facetious here, but that's absurd. It is certainly one of our lowest-level options before reaching for assembly, but it's still a high-level language that abstracts machine details from the programmer.

> In an era where performance mattered, and much software was written for hardware, and controlling hardware, it's hard to see an alternative.

During that era, people who really needed to care about performance used assembly. The optimizations done by C compilers at that time were not nothing, but they were fairly primitive to what they do now.

Re: Rust for Filesystems

#183

Post by marshray »

varjag wrote: post #166
mcronce wrote: post #145

Earlier quoted context omitted.

That's what bindgen is for, as was mentioned in the original comment you replied to.

How well does it handle preprocessor macros in APIs?

I have used it successfully against header files for Win32 COM interfaces generated from IDL which include major parts of the infamous "windows.h". Almost every type is a macro.

This is an extremely well-understood space.

Just open the docs and do it.

Re: Rust for Filesystems

#184

Post by spacechild1 »

commodoreboxer wrote: post #144
varjag wrote: post #126

Earlier quoted context omitted.

That's not really "simple", it's on par with C FFI in about any other language (except C++), with same drawbacks.

It's on par with C++, too. In C++ you need an `extern "C"`, because C++ linkage isn't guaranteed to be the same as C linkage. You can get away with wrapping that around it in a preprocessor conditional, but that's not all that much easier than Rust's bindgen. A lot of C to C++ interop is actually done wrong without knowing it. Throwing a C++ static function as a callback into a C function usually works, but it's not…

I think you're confusing some terms here.

> In C++ you need an `extern "C"`, because C++ linkage isn't guaranteed to be the same as C linkage.

`extern "C"` has nothing to do with linkage, all it does is disable namemangling, so you get the same symbol name as with a C compiler.

> Throwing a C++ static function as a callback into a C function usually works, but it's not technically correct because the linkage isn't guaranteed to be the same without an extern "C".

Again, linkage is not relevant here. Your C++ callbacks don't have to be declared as extern "C" either, because the symbol name doesn't matter. As you noted correctly, the calling conventions must match, but in practice this only matters on x86 Windows. (One notable example is passing callbacks to Win32 API functions, which use `stdcall` by default.) Fortunately, x86_64 and ARM did away with this madness and only have a single calling convention (per platform).

Re: Rust for Filesystems

#185

Post by Someone »

jacobgorm wrote: post #172
lambda wrote: post #119

Earlier quoted context omitted.

Calling C from Rust can be quite simple. You just declare the external function and call it. For example, straight out of the Rust book https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html#usin... : extern "C" { fn abs(input: i32) -> i32; } fn main() { unsafe { println!("Absolute value of -3 according to C: {}", abs(-3)); } } Now, if you have a complex library and don't want to write all of the declarations by han…

Passing integers around is easy, sharing structs or strings and context pointers for use in callbacks crossing the language barrier etc is typically much harder.

For rust code calling C, sharing structs is doable with #[repr(C)]. See https://doc.rust-lang.org/reference/type-layout.html#reprc-s...

(Nitpick: I don’t think it technically is correct to call this “The C representation”, as strict layout in C depends on the C compiler/ABI. I wouldn’t trust this to be good enough for serializing data between 32-bit and 64-bit systems, for example. For calling code on the same system, it’s good enough, though)

Re: Rust for Filesystems

#186

Post by eru »

lanstin wrote: post #164
yjftsjthsd-h wrote: post #153

Earlier quoted context omitted.

I mean people with no ability to alter HN moderation policy. Consider it like this: 1. I think, "oh, that looks relevant, let me open that link". 2. I get a screenful of objections to HN moderation. 3. I shrug and close the tab. Since I'm just a normal user who can't change HN moderation, the outcome is that HN doesn't change but I walk away with a worse opinion of the Asahi Linux folks.

Weird: HN is supposed to be technical but the people behind Asahi Linux have proven themselves to be technical wizards; meanwhile HN seems more interested in money and pseudo-libertarian politics than transformitive technical excellence. But such is our age.

HN has actually drifted far, far to the left of where it started.

It was called Startup News at the beginning. Of course, it's gonna be interested in money and money making. Duh.

Re: Rust for Filesystems

#187

Post by LegibleCrimson2 »

spacechild1 wrote: post #184
commodoreboxer wrote: post #144

Earlier quoted context omitted.

It's on par with C++, too. In C++ you need an `extern "C"`, because C++ linkage isn't guaranteed to be the same as C linkage. You can get away with wrapping that around it in a preprocessor conditional, but that's not all that much easier than Rust's bindgen. A lot of C to C++ interop is actually done wrong without knowing it. Throwing a C++ static function as a callback into a C function usually works, but it's not…

I think you're confusing some terms here. > In C++ you need an `extern "C"`, because C++ linkage isn't guaranteed to be the same as C linkage. `extern "C"` has nothing to do with linkage, all it does is disable namemangling, so you get the same symbol name as with a C compiler. > Throwing a C++ static function as a callback into a C function usually works, but it's not technically correct because the linkage isn't gu…

> `extern "C"` has nothing to do with linkage, all it does is disable namemangling, so you get the same symbol name as with a C compiler.

extern "C" also ensures that the C calling convention is used, which is relevant for callbacks. It's not just name mangling. This is the reason that extern "C" static functions exist. You can actually overload a C++ function by extern "C" vs extern "C++", and it will dispatch it appropriately based on whether the passed in function is declared with C or C++ linkage.

And I'm not sure the terms are confused, because that's how most documentation refers to it: https://learn.microsoft.com/en-us/cpp/cpp/extern-cpp?view=ms...

> In C++, when used with a string, extern specifies that the linkage conventions of another language are being used for the declarator(s). C functions and data can be accessed only if they're previously declared as having C linkage. However, they must be defined in a separately compiled translation unit.

And https://en.cppreference.com/w/cpp/language/language_linkage

The post you're replying to had it completely right. extern "C" is entirely about linkage, which includes calling convention and name mangling.

> As you noted correctly, the calling conventions must match, but in practice this only matters on x86 Windows.

Or if you want your program to actually be correct, instead of just incidentally working for most common cases, including on future systems.

If you're passing a callback to a C function from C++, it's wrong unless the callback is declared extern "C".

Re: Rust for Filesystems

#188

Post by mcronce »

yjftsjthsd-h wrote: post #153
mcronce wrote: post #147

Earlier quoted context omitted.

What? All you need to do is resubmit the request without a Referer header. For me, using Firefox, this meant clicking in the address bar, changing nothing, and hitting enter. That's hardly "no ability to do anything about it".

I mean people with no ability to alter HN moderation policy. Consider it like this: 1. I think, "oh, that looks relevant, let me open that link". 2. I get a screenful of objections to HN moderation. 3. I shrug and close the tab. Since I'm just a normal user who can't change HN moderation, the outcome is that HN doesn't change but I walk away with a worse opinion of the Asahi Linux folks.

It certainly didn't worsen my opinion of the Asahi Linux folks. On the contrary, I commend them for standing up for what they feel is right.

I also doubt they really care whether or not any particular HN reader has a positive or negative opinion of them.

Re: Rust for Filesystems

#189

Post by lambda »

varjag wrote: post #177
kelnos wrote: post #168

Earlier quoted context omitted.

How is that not simple? You just declare the function and then call it. I find it hard to imagine how it could be any more simple than that.

Now imagine a hundred or two functions, structures and callbacks, some of them exposed only as CPP macros over internal implementation. PJSIP low level API is one example.

But... that's what bindgen is for. Which I mentioned.

I said it "can be quite simple"; for simple use cases, just using extern and translating the declarations by hand is perfectly viable.

For more complex cases, you use bindgen.

Re: Rust for Filesystems

#190

Post by googh »

varjag wrote: post #177
kelnos wrote: post #168

Earlier quoted context omitted.

How is that not simple? You just declare the function and then call it. I find it hard to imagine how it could be any more simple than that.

Now imagine a hundred or two functions, structures and callbacks, some of them exposed only as CPP macros over internal implementation. PJSIP low level API is one example.

Can someone shed some light on why the parent comment (by varjag) is downvoted?
Post reply on HN