> Why does yoyoland need to use libc’s memcpy? Can’t you just use __builtin_memcpy?

Unless you do special things, the compiler turns __builtin_memcpy into a call to memcpy. :-)

There is __builtin_memcpy_inline, but then you're at the compiler's whims. I don't think I want that.

A faithful implementation of what you're proposing would have the Fil-C runtime provide a memcpy function so that whenever the compiler wants to call memcpy, it will call that function.

> On Linux, if all you need is syscalls, you can just write your own syscall wrapper-like Go does.

I could do that. I just don't, right now.

You're totally right that I could remove the yolo libc. This is one of like 1,000 reasons why Fil-C is slower than it needs to be right now. It's a young project so it has lots of this kind of "expedient engineering".

You keep repeating the name wrong: yololand, not yololand.

GP was saying 'yoyoland', when it's 'yololand' (as in YOLO?).

Yeah YOLO.

I needed a fun term to refer to the C that isn’t Fil-C. I call it Yolo-C.

Hence yololand - the part of the Fil-C process that contains a bit of Yolo-C code for the Fil-C runtime.

Thanks. I went looking and saw this in the Fil-C manifesto:

> It's even possible to allocate memory using malloc from within a signal handler (which is necessary because Fil-C heap-allocates stack allocations).

Hmm, really? All stack allocations are heap-allocated? Doesn't that make Fil-C super slow? Is there no way to do stack allocation? Or did I misread what you meant by 'stack allocations'?

It’s a GC allocation, not a traditional malloc allocation. So slower than stack allocation but substantially faster than a malloc call.

And that GC allocation only happens if the compiler can’t prove that it’s nonescaping. The overwhelming majority of what look like stack allocations in C are proved nonescaping.

Consequently, while Fil-C does have overheads, this isn’t the one I worry about.

I see! Thanks for that answer. I'm sure I'll have lots of questions, like these:

You say you don't have to instrument malloc(), but somehow you must learn of the allocation size. How?

Are aliasing bugs detected?

I assume that Fil-C is a whole-program-only option. That is, that you can't mix libraries not compiled with Fil-C and ones compiled with Fil-C. Is that right?

So one might want a whole distro built with Fil-C.

How much are you living with Fil-C? How painful is it, performance-wise?

BTW, I think your approach is remarkable and remarkably interesting. Of course, to some degree this just highlights how bad C (and C++) is (are) at being memory-safe.

Malloc is just a wrapper for zgc_alloc and passes the size through. "Not instrumenting malloc" just means that the compiler doesn't have to detect that you're calling malloc and treat it specially (this is important as many past attempts to make C memory safe did require malloc instrumentation, which meant that if you called malloc via a wrapper, those implementations would just break; Fil-C handles that just fine).

Not sure exactly what you mean by aliasing bugs. I'm assuming strict aliasing violations. Fil-C allows a limited and safe set of strict aliasing optimizations, which end up having the effect of loads/stores moving according to a memory model that is weaker than maybe you'd want. So, Fil-C doesn't detect those. Like in any clang-based compiler, Fil-C allows you to pass `-fno-strict-aliasing` if you don't want those optimizations.

That's right, you have to go all in on Fil-C. All libs have to be compiled with Fil-C. That said, separate compilation of those modules and libraries just works. Dynamic linking just works. So long as everything is Fil-C.

Yes you could build a distro that is 100% Fil-C. I think that's possible today. I just haven't had the time to do that.

All of the software I've ported to Fil-C is fast enough to be usable. You don't notice the perf "problem" unless you deliberately benchmark compute workloads (which I do - I have a large and ever-growing benchmark suite). I wrote up my thoughts about this in a recent twitter discussion: https://x.com/filpizlo/status/1920848334429810751

A bunch of us PL implementers have long "joked" that the only thing unsafe about C are the implementations of C. The language itself is fine. Fil-C sort of proves that joke true.

> Not sure exactly what you mean by aliasing bugs.

I meant that if the same allocation were accessed as different kinds of objects, as if through a union, ... I guess what I really meant to ask is: does Fil-C know the types of objects being pointed to by a pointer, and therefore also the number of elements in arrays?

It’s a dynamically typed capability system.

So, if you store a pointer to a location in memory and then load from that location using pointer type, then you get the capability that was last stored. But if the thing stored at the location was an integer, you get an invalid capability.

So Fil-C’s “type” for an object is ever evolving. The memory returned from malloc will be nothing but invalid capabilities for each pointer width word in that allocation but as soon as you store pointers to it then the locations you stored those pointers to will be understood as being pointer locations. This makes unions and weird pointer casts just work. But you can ever type confuse an int with a pointer, or different pointer types, in a manner that would let you violate the capability model (ie achieve the kind of weird state where you can access any memory you like).

Lots of tricks under the hood to make this thread safe and not too expensive.

So Fil-C has two types: pointers, and everything else. Clever.