3 ms·
> Interface informality is the root cause of unsafety I feel this frequently with C. I would love to formalize pointer use in interfaces. But Xr0's proposed sy
by throwawayk7h 3y ago
> Interface informality is the root cause of unsafety
I feel this frequently with C. I would love to formalize pointer use in interfaces. But Xr0's proposed syntax is clunky and not backward-compatible.
void foo(int* x) ~ [ free(x); ];
Yikes... Why not
// <xr0.h>
#ifndef __XR0__
#define freed
#endif
// my code:
void foo(int* freed x);
Boom. Looks clean, easily readable, backward compatible with standard compilers.
- akiarie 3y agoThe reason for the new annotation syntax is the annotations are much richer in their details than merely stating when an object is freed by a function. They can express subtle preconditions, such as the expectation that a pointer refer to a region that is heap-allocated, or be a valid lvalue or rvalue, and so on, and also capture more general side effects. As per the issue of backward-compatibility, Xr0 strips the annotations with a simple command: `0v -s`, producing C source that works with C compilers.
- throwawayk7h 3y agoIt would be nice to be able to compile all Xr0 code directly with a regular C compiler though. It's more convenient than running it through a program, which is a bit of a headache sometimes. For complicated annotations, instead of void foo(int* x) ~ [ free(x); ]; They could do: #include <xr0.h> void foo(int* x) XR0( free(x); ); Then this will compile in a standard C compiler (assuming the XR0 macro is defined properly in xr0.h)
- akiarie 3y agoIt's one more step in the build process. Maybe one day we'll imitate Zig and let C compilers be called via Xr0 though. It also buys as the possibility of beauty. Shoehorning the annotations we're introducing into the preprocessor leads to constructions that aren't nice.