-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Memory leak warning at compile time #396
Comments
Good idea, but I still feel like we should do a bit of garbage collection, at least with free() when the user has used malloc() and the recycling conditions are met. |
Once again, I don't want to add more magic to Jou. I want it to be a simple language that doesn't hide things from you. IMO such language shouldn't magically clean up your garbage. That said, I believe that with good warnings, garbage collection will be only a very small inconvenience. |
And if the compiler is mistaken in some cases, there should be a way to notify it :). |
Undefined variables are a bit similar. There are currently two warnings:
If you get a "may be undefined" warning, you should probably rewrite that part of your code anyway, because it's confusing. For memory leaks, I only want one warning. Something like:
A "may need cleanup" warning in Jou would either spam you with lots of false positive warnings, or it would be so complicated that it's basically impossible to implement. |
It would be nice to get errors for a
malloc()
whose return value is neverfree()
d. However, I don't want:Jou should still feel like C. It would just emit warnings for some common memory management mistakes.
For example, consider:
The decision tree for this function is basically:
If the compiler knows that
fopen(...)
returns something that needs cleanup, andfclose(f)
does cleanup tof
, it could deduce thatf
may already contain something worth cleaning up when we get tof = fopen(...)
. It could then generate a warning that looks something like this:IMO we shouldn't distinguish various different kinds of things to be cleaned up. It is rare to accidentally use
free()
on a pointer that came fromfopen()
. It is much more common to forget the cleanup entirely or do it twice.The text was updated successfully, but these errors were encountered: