fix #3764

[Cyan4973]

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.