John Starks

@filpizlo What were they checking for with cpuid that didn’t require further inline asm?

libwebp 1.4.0 works in Fil-C. Just had to change some inline assembly for cpuid to call `__get_cpuid` instead.

@filpizlo @redneckleeusmc But good for Fil-C that the first one is UB, right? Improves the odds that things will work without patches. The rest are obnoxious. I especially loathe the TBAA stuff, Rust got that one right.

That’s a terrible example of UB since it’s not even really a language issue. The kind of UB people rely on is: - casting pointers to integers and then doing fancy math and then casting back to pointer - casting between pointer types while doing accesses to the same address (ie violating strict aliasing). Also, violating the active union member rule - intentionally overflowing signed integers - performing misaligned accesses And so on

It's amusing that folks think that there is only one load-bearing C99 program that depends on things that the C spec calls UB. (It's harder to find a C program that *doesn't* depend on what the spec calls UB. If we're talking about load-bearing then it might be the null set.)

@redneckleeusmc @filpizlo Sure. But it’s usually shortsighted to depend on behaviors that differ between mainstream vendors. realloc(p,0) is a bad idea if you ever want your code to run on both Linux and BSD, for example.

@gigastarks @filpizlo Because different dialects do different things and that's okay. Different compiler options do different things and that's okay. Not everything in life needs to be micromanaged by a standards committee.

@redneckleeusmc @filpizlo If these behaviors are fine to depend on, then why not fix the C standard to guarantee them? Why won’t the committee agree to that?

@filpizlo It will never not annoy me that many people—especially Rust zealots—assume UB means memory corruption and unpredictable behavior. realloc(p, 0) is fine, but check docs to make sure you know what it does. fwrapv is fine depending on use case. UB is not inherently dangerous.

@filpizlo How do signal handlers for hardware exceptions (SIGBUS, SIGILL, etc.) work? They can't be deferred to a safepoint.

I wrote up how Fil-C uses and implements safepoints! fil-c.org/safepoints

@filpizlo @lcc_27 Yeah, makes sense. What does lower fidelity look like?

@gigastarks @lcc_27 That's true if: (1) you wanted to get to the level of fidelity I have on Linux, and (2) you're not Microsoft. The way to think of Fil-C if you're an OS builder is that it's an opportunity to create a new ABI slice that is totally memory safe. It's expensive, sure, but doable

Behold! Version 0 of a website! fil-c.org

@filpizlo @lcc_27 I think for Windows you’d need to create a much wider “syscall” layer wrapping all the Win32 APIs you want to support, since you can’t rebuild the system DLLs with the Fil-C ABI. This seems impractical.

@lcc_27 Good question. I think that for Fil-C to have support for other OSes, it would have to be something contributed by other volunteers.

@filpizlo Because IIUC, everything in your binary has to be built with Fil-C—it’s a new ABI, incompatible with existing libraries. So if your C code uses a Rust lib, you can’t use Fil-C today.

@filpizlo How much of Fil-C is in clang vs llvm? What would it take to extend Fil-C to support other LLVM-backed languages (such as Rust)?

I love the Fil-C name but it is confusing - makes folks think that this is a language. It’s not. It’s a memory safe implementation of C and C++. Maybe it should be called filcc Or maybe there’s a better name I haven’t thought of yet

@filpizlo @learntToCode Are syscalls really that different with Fil-C? I.e., Fil-C needs some encoding of the semantics of the syscall in order to validate inputs, right? No different from writing a safe wrapper around an (unsafe) syscall. Just a question of where the escape hatch is.

The borrow checker is stronger if you can make your whole program conform to it. And that’s the problem. You won’t get your whole program to conform to it; you’ll have unsafe blocks for syscalls and your wackiest data structures. But in Fil-C, all of that passes Fil-C’s checking - no unsafe escape hatch needed

Status of Fil-C. - Reliably achieves memory safety for C and C++ with stronger guarantees than rewriting in Java or Rust. Much stronger guarantees than asan/valgrind/softbound/hwasan/mte (those aren’t memory safe at all! Too easy to bypass). Similar guarantees to CHERI, just on stock HW. - Stable enough for production use. I’ve tested 100s of C/C++ programs. Most work with zero changes, or just minor build system changes. The compiler is clang 17 based so you get all of those features. - Performant enough for many use cases. Some programs experience less than 2x overhead or even zero perceptible overhead. Text editor, shells, cmdline utilities just work and you won’t notice a perf hit. - Only available on Linux/X86-64 and requires its own ABI slice. Easy to port to other platforms, I just don’t have time for that. - More than zero users. - Zero high profile users have publicly (or even privately) said they are using it, but that doesn’t mean that there aren’t any. - Still a solo project. If I got hit by a bus then the project would likely die. It’s a fun state to be in. Like, maybe there is a high profile user and I just don’t know it. Maybe the low profile folks using it will find great success in whatever they are doing with Fil-C. Anything is possible

Very proud to announce that the Windows Subsystem for Linux is now open source! blogs.windows.com/windowsdevelop…

@burntsushi5 Finally, an explanation for your moniker.

This week is the first time I used a rice cooker. Wow! I knew they existed before, but it just never really entered my awareness. In terms of convenience, it's like sous vide, but for rice. Total game changer in terms of time management for dinner prep.

@gerhart_x @clift_m We are working on improving the TLFS. If you have specific areas you’d like to see addressed, let me know.

@clift_m Yes, there was Hyper-V TLFS, but it outdated. Current online version isn't full: learn.microsoft.com/en-us/virtuali…. OpenHCL and Openvmm don't contain all hypercalls. It was complete in Windows Server 2008 hvix64\hvax64 symbols first

Wow, Grok is right in something )

I created a hypervisor-based emulator for Windows x64 binaries. This project uses Windows Hypervisor Platform to build a virtualized user-mode environment, allowing syscalls and memory accesses to be logged or intercepted. elastic.co/security-labs/… Project: github.com/x86matthew/Win…

@kromych @x86matthew Should work… we added support a good while ago for hot add of VP after partition setup.

@x86matthew Very cool stuff, thanks for sharing! If WHvCreateVirtualProcessor was allowed (is it?) after setting the partition up, that might’ve been the way to model threads, albeit the limit is 2048 VPs/partition iirc. The hv then would do the scheduling, VPs would share CR3…

I hate generic ‘utils’, ‘helpers’ and ‘miscellaneous’ directories and modules in software projects. But it’s been surprisingly hard to get rid of them. I feel like there’s a lesson here. Every house has a storage box where you just store random stuff.

@charliermarsh @stanzillaz Hey, thanks. I’ll give it another go soon.

@gigastarks @stanzillaz This should fix it (assuming you're on macOS): github.com/indygreg/pytho…

So, I’m trying to install manim and… are Python people okay?

@stanzillaz @charliermarsh Looked promising, but I hit some known bug where it hard codes some CFLAGS or something from their build machine, and those flags reference paths that don’t exist on my machine, so random dependencies fail to build.

@gigastarks Use UV by @charliermarsh