But it’s strictly less safe than either Fil-C or Rust since it only protects bounds

Fil-C is more precise than valgrind or asan. Valgrind and asan will allow a buggy access (like an OOB) to succeed if the resulting address is valid at all - which is useless from a security enforcement perspective since clobbering valid addresses is what the attacker is trying to do.

Fil-C only allows an access to succeed if it’s in bounds of that pointer’s capability. That is a useful level of precision for security, since it prevents the attacker from clobbering the addresses of their choice.

"Fil-C has no unsafe statement and only limited FFI to unsafe code."

`zunsafe_call` is a weird thing to get hung up on as an "escape hatch", considering it's just a super limited form of FFI, intentionally designed so that it's only usable for OpenSSL's use case.

> Misrepresenting `unsafe{}`

`unsafe` lets you write Rust code that violates any reasonable definition of memory safety (including Rust's definition or my definition), and it's widely used.

By contrast Fil-C has a small number of rules and largely obviates the need for “native” code.

The OP is about Zig and now there are 40+ mentions of Fil-C initiated mostly by Rust folks and those comments are largely criticizing me personally.

That’s toxic AF!

As a long time PL researcher, I can, should, and will point out interesting corner cases of languages. Including in Fil-C or Rust

I never said Fil-C is “so much better” (let alone with all caps) than anything.

I never called Rust “trash”.

I think you’re taking this all too personally

I make bold claims because they hold water.

- You can at worst corrupt only the capability you’re pointing to.

- intra object overflows are almost never useful for memory corruption exploits unless they let you corrupt a pointer, and Fil-C prevents that from being useful because you cannot corrupt the capability.

- the zunsafe api is basically unused. One library uses it (OpenSSL) for good reasons. This is in contrast to widespread use of the unsafe keyword in Rust, beyond just one library for a narrow purpose.

Thanks for reporting bugs. Worth noting that they require doing things that extant C code never does. It’s good to fix those, but the true threat model of any memory safe language is not to sandbox a malicious programmer, but to protect the program of a normal programmer against a malicious user

CanadaHonk has gotten further than the rest of us. It’s surprising and impressive.

You’re only replying to the quickjs issue I raised, but it’s not the only issue. Their approach to numbers is broken. Their approach to measurement is broken. The quickjs thing raises another red flag: it suggests to me that they are using reference counting, not GC. That’s guaranteed to make them too slow to be useful. (If they weren’t using RC, then they’d have a hard time on the boundary to quickjs.)

As to the `any` issue, let me explain it in a way you’ll appreciate. I asked Claude how likely it is that TS code uses any, and it found:

- 79.5% of TS repos use any explicitly. So, about 4/5 chance that newly written dep-free TS code will use it.

- the explicit any type is about as common as Boolean and void.

- a third of inferred types are any. That’s huge.

So, if you don’t believe me, then at least believe Claude: any is a super common type, so they will be falling off into quickjs a lot.

Oh, and in case it isn’t clear, quickjs-ng is no better than quickjs. They’re the same thing for the purpose of perf

Note that “untyped dependency” means any code that says `any`.

- using quickjs at all in a thing that needs perf. Quickjs is hilariously slow. Midwits use it because it has “quick” in the name.

- using floats for numbers and deferring int optimizations for later. Inferring ints is like half the problem of fast JS.

- rejecting inadequately annotated or too dynamic code without a whole heck of a lot of self-reflection about how unlikely that is to work out.

The observation that languages that are even slightly dynamic need dynamic JIT opts is very old; folks figured that out in the 80s.

This project reeks of weapons grade AI psychosis

- the architecture is idiotic.

- they have zero credible perf numbers.

I plan to benchmark it using generally accepted methods.

Porffor makes careful trade offs that make sense and is benchmarked in a way that I can believe.

(Source: I make dynamic languages fast for a living)

I have added the nuance. Folks now understand that there are limits to Rust’s memory safety.

What have you added to the conversation? Nothing.

We should do more of that as a community. It’s important stuff. Ima do my part so you’ll likely see me poke at how Fil-C does a thing that Rust doesn’t do. If you read my arguments unemotionally, I think you’ll get a deeper appreciation for Fil-C, Rust, and memory safe language design generally.

What we shouldn’t do is reduce the discussion to claiming in a blog post that so-and-so “doesn’t like” such-and-such.

The closest technique to invisicaps is softbound, but that has issues that invisicaps resolve (better story for races, more comprehensive safety for all of the C and C++ languages, no need for large virtual memory reservations, and lock freedom)