3 ms·
The 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
by akiarie 3y ago
The 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.