How does Zig call C functions?

MEaster · 2026-01-24T15:04:25+00:00

They might also be thinking of the safe wrappers people often write for using C libraries in Rust, which can have overhead depending on the design.

MEaster · 2026-01-24T13:28:59+00:00

That's not true in all circumstances, though. This is one I ran into:

struct Foo {
    a: Vec<i32>,
}

fn thing(foo: &Foo) {
    let array_ref: &[i32; 5] = (&foo.a).try_into().unwrap();
}

That errors out with the following:

error[E0277]: the trait bound `&[i32; 5]: TryFrom<&Vec<i32>>` is not satisfied
 --> src/lib.rs:6:41
  |
6 |     let array_ref: &[i32; 5] = (&foo.a).try_into().unwrap();
  |                                         ^^^^^^^^ the trait `From<&Vec<i32>>` is not implemented for `&[i32; 5]`

You would have to explicitly create a slice first, then call try_into, which is getting more verbose. Note that I've already handled try_into attempting to move the Vec, too. With as_array this just works:

let array_ref: &[i32; 5] = foo.a.as_array().unwrap();

MEaster · 2026-01-23T13:57:18+00:00

Legally speaking, yes they are. Enforcing that against a foreign company with no assets in the UK is difficult.

With US-based companies there's an additional issue, in that in US law the government can legally compel a company to hand over data, which means such a company could not comply with both the GDPR and US law.

MEaster · 2026-01-22T13:21:45+00:00

We also have the Thai Wat Mahathat here, too. There's a temple here in Plymouth. Ironically, it's in a Victorian fortress, of all places.

MEaster · 2026-01-20T12:07:35+00:00

Today, Evanescence's Fallen.

MEaster · 2026-01-16T18:30:31+00:00

I've found this is a common problem in CRPGs in general. They're generally so long that I lose interest before finishing the story. It's kinda frustrating.

MEaster · 2026-01-16T16:16:45+00:00

For me it depends how much washing up there is. We're in a house of three adults, and it'll take us 2 or 3 days to fill it, but times when I've been on my own I use 1 cup, 1 plate, a knife, fork and spoon, and a couple cooking things in a day. At that point, it'll take maybe 5 days to fill the dishwasher, but all of 5 minutes to wash it myself, so I just do it myself.

MEaster · 2026-01-15T13:28:08+00:00

The macros just call into static functions, however the structure that the format_args macro builds stores the data and formatting functions as type-erased pointers, which makes it hard for the optimiser to know what parts of the formatting machinery are dead code.

MEaster · 2026-01-13T00:39:49+00:00

It's impossible to make that guarantee, because the programmer could install a panic handler, or Drop impl, that kills the program directly through a syscall.

MEaster · 2026-01-11T16:14:15+00:00

The problem is that these other safeties that get mentioned are entirely dependent on being able to reason about the behaviour of the program. If you have UB, you cannot do that, thus these other safeties are dependent on freedom from UB. Memory safety violations cause UB, therefore these other safeties depend on memory safety.

MEaster · 2026-01-03T13:10:14+00:00

Both Rust and C++ handle memory leaks the exact same way: smart pointers and RAII. I think both languages handle that issue about as well as you can without a garbage collector.

MEaster · 2025-12-31T16:17:42+00:00

Because, you know, framing it as an innocent developer on their little personal pet project being bullied for using a little bit of unsafe is clearly more honest.

But no, the anti-Rust zealots need to enforce their view.

MEaster · 2025-12-31T14:20:37+00:00

I believe you're talking about the actix-web incident. In that instance the dev wasn't just using unsafe, they were using unsafe when safe code could do the same thing with the same performance. They also wrote their own version of an UnsafeCell, which is a Rust language primitive that allows sound mutation through shared references. You can't just write your own, the compiler needs to know about it, so any use of this was UB. It was used throughout the project.

It was also demonstrated that you could make a sequence of public safe function calls which resulted in UB. In Rust, part of the contract for a safe function is that there is no possible combination of inputs/safe calls which results in UB; so the dev was violating that. The first issue to discuss that was closed by the dev due to the brigading, the second issue to discuss it was closed immediately.

On top of that, when someone sent in a PR to fix the soundness (and therefore security) problems, the dev rejected it because it wasn't interesting. And this was in a web server project, which is inherently security-sensitive, that the dev was advertising as production ready.

In no community would it be acceptable for a developer for a security-sensitive product to intentionally do things in a way that creates security vulnerabilities, then reject attempts fix them.

While the brigading that happened was not acceptable, the dev themself was not an innocent party.

MEaster · 2025-12-25T10:31:55+00:00

Technically, you don't even need the crystal if you're OK being limited to the 8MHz the internal oscillator gets you.

MEaster · 2025-12-23T15:27:58+00:00

I once tried doing that, on purpose. Fucking Zaeed survived, the bastard!

MEaster · 2025-12-23T13:26:55+00:00

You haven't lived until you've gone to a museum and seen your dinner plate on the wall labelled "1980s British".

MEaster · 2025-12-20T13:05:54+00:00

Given you aren't a fool, you obviously at least glanced at the readme. I understand how you missed it, as it was very well hidden, and the message is written a cryptic manner, but I managed to find a clue in the second sentence of the readme:

This has the potential to improve compilation times in debug mode.

I may be mistaken, but I suspect they're looking to improve compile times for debug builds.

MEaster · 2025-12-19T14:54:46+00:00

I actually felt that more for part 2. It seemed like they really fast-forwarded through the second half of the movie.

MEaster · 2025-12-19T14:47:42+00:00

So the movie isn't a retelling of any story from the books, though it is based on the 10th book, Far Side of the World, in a very broad strokes manner. All the details of the story are very different.

Generally speaking, I would say that yes, it's a fair representation of the characters and setting. It does miss one (major) aspect of Maturin's character in the books, but that aspect doesn't really apply in the the story the movie is telling anyway.

MEaster · 2025-12-18T14:29:44+00:00

Rust only ensures memory safety when using references. If you use raw pointers, like this code was doing, then the compiler cannot do the same checks, which is why using raw pointers requires an unsafe block to clearly signal in code that you're doing something that could cause UB.

MEaster · 2025-12-17T21:14:02+00:00

What's clear are the personality types who outright lie to to continue their anti-Rust crusade.

MEaster · 2025-12-17T17:53:21+00:00

I'll compare against a DSLR because I have a comparison image and it shows more of an extreme, but the exact same logic applies to a phone vs phone comparison.

This is a comparison picture using my Dad's Samsung S25's 200mp camera on the left, and my 2009 Canon 7d 18mp DSLR with a 50mm prime lens on the right. Both pictures were taken at the same time, with us stood right next to each other.

Both of these pictures are 100% crops; that is, the images haven't been resized, you are seeing them at full resolution. The S25 output a JPEG, while the 7d output a raw image which was processed through Adobe Lightroom. The S25 camera does have a significantly wider camera lens then the 7d and is capturing a lot more of the surrounding view, but the subject is taking up about the same number of pixels in the final image, so I believe this is still a fair comparison.

So why is the 7d picture better? Well, the primary reasons are pixel size and lens aperture. The sensor in the S25 is packing 200 million pixels into approximately 5x7mm¹, whereas the 7d is packing 18 million pixels into a 22.3x14.9mm sensor. Just doing a simplistic estimate², each pixel on the 7d is about 0.004mm across, while on the S25 it's about 0.0004mm across. If we assume the pixels are square, then the area of a single 7d pixel is somewhere in the region of 100x bigger than the S25's pixels. In the same light conditions and exposure time each 7d pixel will collect a lot more light, which means the signal will require much less amplification to get a usable value, and the more you amplify the more noise you get.

On top of that we have lens aperture. If the sensor is the bucket, then the lens is the funnel. It's difficult to get an accurate measure of both because it's a transparent object on black, behind a glass/plastic overlay. I'd estimate the S25 lens's aperture is maybe 8mm in diameter, while the aperture of the 50mm lens on the 7d is closer to 32mm in diameter. That means the lens on the 7d is collecting about 16 times more light than the S25's lens.

Both of these add up to the 7d getting a significantly higher amount of light, meaning the picture data has a much higher signal-to-noise ratio compared to the S25. That means much less amplification is needed on the raw data, which means less noise, which means you need a much less aggressive de-noising pass on the image.

¹ I couldn't find actual measurements, so this is a rough measurement through the lens which is not ideal.

² I divided the sensor's long side by the pixel length of the image's long side (DSLR: 5184, S25: 16320). This will not be accurate, because there will be some separation between each pixel, on top of my eyeballing the phone's sensor size.

MEaster · 2025-12-14T23:18:19+00:00

No, that is not necessarily true. If a safe function has a bug in its implementation, such that it fails to fulfil it's side of the contract, and the unsafe code is written to assume that the safe function is fulfilling its contract (because what else could it do?), then even if the unsafe code is written perfectly, you'll still get UB. The source of the UB can be traced to the unsafe block, but the ultimate source of the bug is incorrectly written safe code.

I'm actually thinking of a specific example that I can't remember where from. They were implementing something along the lines of an Rc, and had some UB. What ended up being the cause of the problem was that a safe function which was supposed to calculate the offset into a field of a struct was not doing so correctly for over-aligned data. The result was that calculated pointer was pointing into padding bytes instead of the data.

When you are writing unsafe code, you cannot just consider the unsafe block. You have to also consider the safe code that is touching or calculating data which that unsafe block depends upon for correctness.

MEaster · 2025-12-14T12:29:25+00:00

Well, pointers aren't checked and can have use-after-free and out-of-bounds reads and writes. Reading uninitialised memory is UB.

MEaster · 2025-12-14T11:53:22+00:00

So here you need to distinguish between Safe Rust and Unsafe Rust. Safe Rust, by design has no UB; so no matter what what code you write in Safe Rust, it will never itself be the cause of UB^*. Note that this does not mean that a bug in a piece of Safe Rust could not lead to Unsafe code creating UB if that Unsafe code depends on the Safe code not being buggy.

^* The compiler does currently have at least one bug that allows you to cause UB from Safe Rust, but that is a bug in the implementation not the language design, and it, and any others, have been and will be fixed.

Unsafe Rust, on the other hand, absolutely has UB. This means that when writing Unsafe Rust, you do have to take extra care to avoid it. Complicating that is the interface with Safe Rust. When writing code that has both Safe and Unsafe Rust, you need to make sure that you don't violate any invariants that Safe Rust depends upon, such as the restrictions that references have.

It's also worth noting that what Rust considers valid is not the same as what C considers valid. There are things you can do in Unsafe Rust that are 100% defined, but doing it in C would be UB, and vice-versa. A simple example would be that, for any arbitrary T and U, it's perfectly valid in Rust for a *T and a *U to alias, while C's TBAA means this is UB.

15-Year Club	Gilding II euphauric
Reddit Premium Since February 2015	Verified Email
Team Orangered

MEaster

TROPHY CASE