Skip to content
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

fix #3764 #3765

Draft
wants to merge 1 commit into
base: dev
Choose a base branch
from
Draft

fix #3764 #3765

wants to merge 1 commit into from

Conversation

Cyan4973
Copy link
Contributor

This answer a static analysis tool, in #3764,
which complains that an allocated buffer is not free() just before exit().

In general, this requirement is not necessary, because invoking exit() terminates the process, and makes the OS reclaim all its memory.

I could articulate this additional requirement in a "not too heavy" way with the use of a new macro, CONTROL_EXIT().
But "not too heavy" is still a form of maintenance burden: whenever the code is modified, by adding, removing or changing some of these buffers, it requires some manual coordination with exit points, which is easy to let go wrong.
Besides, I wouldn't be surprised if there were some more complex scenarios left, typically across multiple levels of functions, where a call to exit() is made while some other buffers, inaccessible from the function, are still allocated. Tackling such issues would require a very different approach, typically forbidding the use of exit(), which was meant to simplify code maintenance by reducing the nb and complexity of error paths.
I question the need to make the code more complex to read and maintain, just to tackle some largely theoretical issue with no practical impact on target platforms.

@Cyan4973
Copy link
Contributor Author

It seems we have some issues with the x32 test these days.

../programs/zstd: Exec format error

Note sure what's going on.
This test error is unrelated to this PR, since it's also failing for other PRs.
But it's an annoying red signal in our CI, and will likely deserve a fix.

This answer a static analysis tool,
which complains that a buffer allocation is not free() just before exit().

In general, this requirement is not necessary, because invoking exit() will make the OS reclaim all buffers from the terminated process.

I could articulate this new requirement in a "not too heavy" way with the use of a new macro, `CONTROL_EXIT()`.
But "not too heavy" is still a form of maintenance burden: whenever the code is modified, by adding, removing or changing some of these buffers, it requires some form of coordination with exit points, which is easy to let go wrong.
Besides, I wouldn't be surprised if there were some more complex scenarios left, typically across multiple levels of functions, where a call to `exit()` is made while some other buffers, inaccessible from the function, are still allocated. Tackling such issues would require a very different approach, typically forbidding the use of `exit()`, which was meant to simplify code maintenance by reducing the nb and complexity of error paths.
I question the need to make the code more complex to read and maintain, just to tackle a largely theoretical problem with no practical impact on target platforms.
@Cyan4973 Cyan4973 marked this pull request as draft January 13, 2024 19:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants