In article <alpine.neb.2.00.1212171106140.2...@galant.ogmig.net>,
Iain Hibbert <plu...@ogmig.net> wrote:
>
>I didn't understand it, in any case.. can you explain why, in C, when
>exit() explicitly closes all open file descriptors and releases any memory
>etc (see a detailed list in exit(3) and _exit(3)), there might be a
>benefit in doing so formally before calling exit() ?
It is a slippery slope. Every program eventually exits, so it is up
to the author of the code to decide when it is late enough to avoid
doing cleanup. I think that everyone agrees that libraries should
have as few side effects as possible and free resources when they
are not needed. In the application case, this is not so clear. There
are claims of:
- loss of readabily
- slowing down exit
- the OS does not free resources until process destruction anyway
On the other side there is:
- memory usage/leak tools complain
- destruction path gets written/tested
- code gets reused/refactored in different places, and then
the leaks become apparent
- sloppiness and laziness is not good programming practice
- buncombe :-)
And don't know, are there any others?
My experience has been that in the past, when I had to add resource
deallocation on code that did not do it before, it has been a complex,
time consuming, and error prone task. The main reason for that was
that the people who designed the code relied on the fact that there
would be no resource deallocation. This led to bad coding practices
throughout the code (why keep the original pointer around when we
are not planning to free it anyway; we can just move it around).
All these design decisions required heavy-handed structural changes
to the code to make it use resources properly.
So, I design for code reuse; I like to be able to use memory leak
detectors, and I've had to deal with programs that did not do so
well about resource allocation in the past (make, csh) so I appreciate
code that is designed with deallocation in mind.
christos
