How does it compare to the equivalent code in Typescript, Go or C#? Those languages all have “safe” syscall wrappers too, for a subset of syscalls.

▲

pizlonator 2 hours ago | parent [-]

Those languages rely on a much larger pile of YOLO C/C++ code for their runtimes and standard libraries than Fil-C does.

So Fil-C is safer than those

▲

josephg 2 hours ago | parent | next [-]

The number of lines of raw C isn’t the only way to measure the trustworthiness of a codebase. Go, C# and friends may be bigger projects. But they’re also more mature projects. At this point, far more eyeballs have scoured their codebases looking for security bugs.

> Fil-C is safer than those

Says you. It seems presumptuous to me to be so dismissive of their work. The Go and C# teams do good work.

But I wasn’t even asking about safety. I’m curious about ergonomics and performance. Fil-C isn’t the only safe wrapper around raw syscalls. How is cross OS compatibility with Fil-C? How nice are the APIs to use? UNIX syscalls are pretty badly designed imo. The error paths alone are a mess.

▲

ncruces 2 hours ago | parent | prev | next [-]

Go doesn't rely on much C/C++, not recently at least. Particularly on Linux.

▲

Splizard 2 hours ago | parent | prev [-]

Small nitpick but Go doesn't really have any YOLO C/C++ code in its runtime and standard library.

▲

pizlonator 30 minutes ago | parent [-]

Yeah what I said is true of TS and C#, but not of Go.

Go’s situation is nuanced since a lot of Go code does rely on unsafe C or C++ deps, but I have no idea how generally true that is. Also Go’s protections fall apart under certain races, which isn’t true in Fil-C.

	▲	quotemstr 14 minutes ago \| parent [-]
		Races in Fil-C allow access to one object through a pointer to a different object if there's an attacker-controlled offset involved. Fil-C's safety guarantees therefore fail to apply in this situation.