pizlonator

3 ms·

1.
by pizlonator 7d ago
> I’m not sure if you were getting at this by mentioning the ABI specifically Fil-C dynamically links its runtime, and it's a goal to support having different runtime versions link against code compiled by different versions of the
2.
by pizlonator 8d ago
Not sure that protobuf change is the same thing But you might be right on your overall point: on my big x86 CPU, it doesn't matter, but it might matter on some tiny arm thingy
3.
by pizlonator 8d ago
Super interesting! Fil-C's GC has basically always had size-specialized allocation and I've done some experiments with this so I have my own data. As the post says, there are two potential benefits: - Faster memory clearing when t
4.
by pizlonator 9d ago
This is neat. But the benchmarks are tiny, and it’s likely that Goose was tuned on them. So, I think I would read this as: Goose has competitive performance to C and Rust and I’ll take them at their word that it’s as memory safe as Rust
5.
by pizlonator 11d ago
The wild thing about locks in particular is that microbenchmarks will cause you to make „optimizations” that are the opposite of what benefits real world workloads.
6.
by pizlonator 12d ago
Super dangerous to benchmark lock performance using microbenchmarks. If you have a tiny benchmark, then you're putting the CPU and memory into a very specific and unusual state (everything is quiet other than the lock itself). The real
7.
Just testing my memory safe web browser
2 points by pizlonator 15d ago|1 comments
8.
by pizlonator 21d ago
> easy to be safer It took over two years and help from contributors to get to the point where WebKit could be made fully memory safe.
9.
by pizlonator 21d ago
How would memory safety have not made a difference?
10.
by pizlonator 21d ago
I'll port Epiphany eventually. WebKit's JS engine (JavaScriptCore) is super friendly to pointer capabilities. I did not have to change much to make it use the Fil-C GC instead of its own GC and to make it use a capability per JS o
11.
by pizlonator 21d ago
Nah It's damn near impossible to verify that the JIT is correct. But it is possible to verify at runtime that the code that the JIT emitted obeys some memory safety law. (V8's heap sandbox is an example of this; a sarcastic JIT wo
12.
by pizlonator 21d ago
lol yeah Pls file bugs if you encounter issues. Also, fair warning, it's hella slow right now on JS-heavy websites (like X). It barely works. But we can fix that with some effort, I think
13.
by pizlonator 21d ago
Yes I have a new tech called SaRCAsm, which is a memory-safe assembler. So the next step is a "Sarcastic JIT" :-)
14.
by pizlonator 21d ago
VM https://fil-c.org/pizlix Then build WebKit using do_cmake_yolo_simpler.sh in projects/webkitgtk-2.44.3 It's still pretty rough, but works more than well enough to post on HN. My regression test is to post on X.
15.
by pizlonator 22d ago
Yeah
16.
by pizlonator 22d ago
There's a risk that someone had been sitting on a sandbox escape that assumed having RCE inside the sandbox first, and so they'd been waiting for an RCE exactly like this one. Those folks would not be disclosing their sandbox esca
17.
by pizlonator 22d ago
I think the problem is that we've let JS engines become absurdly complex so there's no way to avoid them having really gross bugs. That said, I think that the V8 team has done a fantastic job of securing their engine. Their heap s
18.
by pizlonator 22d ago
Sounds wild. (Posted from memory safe WebKit; i.e. WebKit compiled with filcc and all of WebKit's dependencies compiled with filcc.)
19.
by pizlonator 26d ago
This doesnt seems to be meaningfully different from Rust. > does not require tracing garbage collection Just call it garbage collection. (Applies in two ways: if you think that garbage collection subsumes reference counting then this lan
20.
by pizlonator 1mo ago
That is a great feature But it’s strictly less safe than either Fil-C or Rust since it only protects bounds
21.
by pizlonator 1mo ago
Correct
22.
by pizlonator 1mo ago
Yeah rlbox is great. 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
23.
by pizlonator 2mo ago
From the second paragraph of fil-c.org: "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 limi
24.
by pizlonator 2mo ago
Genius.
25.
by pizlonator 2mo ago
How do you enforce this?
26.
by pizlonator 2mo ago
I have worked on both a major JS runtime and a .NET runtime. I have fixed hundreds of security bugs in JSC. Based on that, I have no doubt that what Fil-C does is safer. Just the absence of a JIT makes it safer in a way that I don’t think i
27.
by pizlonator 2mo ago
Saying something that you don’t believe isn’t trolling.
28.
by pizlonator 2mo ago
This thread is evidence of it. 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!
29.
by pizlonator 2mo ago
I never claimed that Fil-C is objectively better than Rust. As a long time PL researcher, I can, should, and will point out interesting corner cases of languages. Including in Fil-C or Rust
30.
by pizlonator 2mo ago
Steve, be reasonable. 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

More ›