One note on last example, "memory leak":
GC for C is awesome, but I wish there were an optional way to ensure it is not doing anything, for example by having the program panic/warn if an allocation was GC'd that was not free()'d before. (I understand it cannot be disabled for safety reasons, to track free()'d pointers)
This would be handy when writing programs for both Fil-C and Yolo-C. A developer would use Fil-C with all the nice diagnostics and for safe release builds; and if a user does not want Fil-C for some reason, well.. they can use regular C compiler. But this can only happen if the program does not rely on any Fil-C-only features, like FUGC.
You are not supposed to change anything on your Fil-C program to have it compiled by a regular C compiler.
FUGC is not a feature your code uses, just something that runs in the background to catch possible use-after-free cases, but triggering them is still an error and you won't want to ship any product with such bugs.
I sort of like the idea of folks relying on Fil-C features and then sticking with it. :-)
Right now, the Fil-C runtime already relies on the GC in that it creates objects that don’t get freed. So it would already be hard to provide diagnostics about leaked objects. And since the GC is concurrent and runs at unpredictable times, any diagnostics it reported would be flaky.
FUGC really is designed to be something you rely on in production as opposed to being a leak detector.
One note on last example, "memory leak": GC for C is awesome, but I wish there were an optional way to ensure it is not doing anything, for example by having the program panic/warn if an allocation was GC'd that was not free()'d before. (I understand it cannot be disabled for safety reasons, to track free()'d pointers)
This would be handy when writing programs for both Fil-C and Yolo-C. A developer would use Fil-C with all the nice diagnostics and for safe release builds; and if a user does not want Fil-C for some reason, well.. they can use regular C compiler. But this can only happen if the program does not rely on any Fil-C-only features, like FUGC.
You are not supposed to change anything on your Fil-C program to have it compiled by a regular C compiler.
FUGC is not a feature your code uses, just something that runs in the background to catch possible use-after-free cases, but triggering them is still an error and you won't want to ship any product with such bugs.
It depends on whether you want to support Yolo-C or not.
If you want to support Yolo-C in your codebase, then don’t rely on FUGC. Free your objects like normal.
But maybe you are writing code that’s all in for Fil-C. Then you might want to rely on FUGC.
I sort of like the idea of folks relying on Fil-C features and then sticking with it. :-)
Right now, the Fil-C runtime already relies on the GC in that it creates objects that don’t get freed. So it would already be hard to provide diagnostics about leaked objects. And since the GC is concurrent and runs at unpredictable times, any diagnostics it reported would be flaky.
FUGC really is designed to be something you rely on in production as opposed to being a leak detector.
How are the pointers implemented?
See here: https://github.com/pizlonator/llvm-project-deluge/blob/delug...