3 Prevalent Themes in the Discussion
| Theme | Summary | Representative Quote |
|---|---|---|
1. Memory‑safety concerns around setjmp/longjmp and related APIs |
Many users stress that these low‑level control‑flow primitives can corrupt memory if mis‑used, making them a key safety target. | “These functions can easily be misused to corrupt memory, so they very much have something to do with safety.” – pizlonator |
| 2. Fil‑C’s approach to making those APIs safe | Fil‑C adds strict wrappers that prevent escaping the capability model and extends safety to sigaction, even when used in signal handlers. |
“Fil‑C goes to great lengths to prevent your use of those functions leading to memory corruption or any violation of the capability model.” – pizlonator |
| 3. Technical nuance of stack copying & pointer relocation | The conversation explores why copying stacks is needed to avoid dangling pointers, and how alternative designs (e.g., base‑plus‑offset) could work in other languages. | “What ruins this for C is the existence of pointers. Stacks aren’t freely relocatable since pointers into the stack could exist.” – matheusmoreira |
Key take‑aways:
- The discussion centers on memory safety of low‑level control flow APIs.
- Fil‑C addresses this with rigorous, capability‑aware wrappers.
- Participants dive into stack‑management techniques (copy‑back, base‑pointer models) that could sidestep the pointer‑relocation problem.