2 ms·

> the zunsafe api is basically unused. One library uses it (OpenSSL) for good reasons Wait, so there are escape hatches? But… you’ve repeatedly said, many time

by orf 2mo ago

> the zunsafe api is basically unused. One library uses it (OpenSSL) for good reasons Wait, so there are escape hatches? But… you’ve repeatedly said, many times, that there are zero escape hatches? And now here you’re saying not only that there only are escape hatches, but there’s a good reason to use them? Damn. Misrepresenting `unsafe{}` whilst saying your language is better because there are no escape hatches and no need for escape hatches is like… 80% of your online personality. When can we expect the website to be updated to remove the misleading claims?

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

by orf 2mo ago

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