Re: CVS commit: src/usr.bin/tic

[Roy Marples <roy%marples.name@localhost>]

On 05/05/2017 12:56, Robert Elz wrote:
>     Date:        Fri, 5 May 2017 11:49:28 +0100
>     From:        Roy Marples <roy%marples.name@localhost>
>     Message-ID:  <d4678b06-236a-286d-eaf8-19d40971a54f%marples.name@localhost>
> 
>   | In this case, exit() isn't called, the main function returns.
> 
> Same thing, return from main is defined as implicitly calling exit.
> 
>   | In the RTEMS case, everything runs in one process and a thread is
>   | launched for each command, sharing memory thus exit() can never be called.
> 
> It doesn't need to "exit" in that sense, but when that thread completes,
> whatever resources it allocated needs to be reclaimed (whether they be
> file descriptors, or memory, or whatever else).   How that is done is the
> implementations business, but it needs to be done.
> 
> If not, you'd have bigger problems with tic if you intended to run it
> on such a system - I see its grow_tbuf(), save_term(), write_database()
> (and main(), though those calls are less of a problem) fuunctions all call
> err() on error.  err() is defined not to return.  No memory gets
> freed, nothing gets closed, other that whatever side-effect of the
> program completing (calling exit) is.

FreeBSD has err_set_exit(void (*exitf)(int)) to handle this.
I suppose atexit(3) could be used as well.
But that's more of a technical nit than suggesting we make tic 100% free
stuff, which is not what I'm suggesting.

>   | So my question stands, is this something we should support via a compile
>   | time guard or just not bother?
> 
> Leave the __VALGRIND__ guard in, and clean up in that case only, not that
> a program like tic should really be too concerned about memory loss,
> because exit (or whatever happens to it when it falls off main) really
> needs to clean up for it, but just in case someone wants to debug
> its memory use (perhaps it might be of use when debugging the hash table
> library functions memory uses - to make sure that when the program does 
> hdestroy*() that everything is freed ... as while tic really doesn't
> care, some other long running daemon program might.)
> 
> Or if debugging memory use in tic isn't important, simply delete the
> whole code block (turn the #ifdef __VALGRIND__ into #if 0, and then
> delete the entire block later.)

Debugging memory use is always important.
I'll move it to a separate function for clarity, but was hoping a better
guard name than __VALGRIND__ could be used.

Maybe __DEBUG_MEMORY__ or __FREE_RESOURCES__?

Roy