]> git.ipfire.org Git - thirdparty/zstd.git/commit
fix #3764 fix3764 3765/head
authorYann Collet <cyan@fb.com>
Wed, 20 Sep 2023 18:17:14 +0000 (11:17 -0700)
committerYann Collet <yann.collet.73@gmail.com>
Sun, 8 Oct 2023 02:34:22 +0000 (19:34 -0700)
commitbfeb456fcd9c3aacfa3ffa144ae99c6c55157099
treedec75cba40e1aacfcf8ef506b1dc5c3870b27f73
parentc692b8d12d08eb3e460f99b43a7568ebbcb27acb
fix #3764

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.
programs/util.c