3 ms·
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
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 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.
- orf 2mo ago> Unlike other approaches to increasing the safety of C, Fil-C achieves complete memory safety with zero escape hatches. Except there is an escape hatch, by your own admission above? > `zunsafe_call` is a weird thing to get hung up on as an "escape hatch" from the docs: > unsigned long zunsafe_call(const char* symbol_name, ...); > Performs an unsafe call to Yolo-land. That’s just a `unsafe{ func(…) }` escape hatch > intentionally designed so that it's only usable for OpenSSL's use case. Cool motive, still an escape-hatch =) Do you have the backbone to update the fil-c website to correct the record, and let the person you retweeted here[1] know that the escape hatch row is incorrect? Or… is what everyone says about you here true? 1. https://x.com/filpizlo/status/2081765923757903940 https://x.com/filpizlo/status/2081765923757903940