Re: reclaiming memory before exit

On Thu, May 14, 2020 at 11:16 PM Paul Eggert wrote: > > On 5/14/20 5:11 PM, Jeffrey Walton wrote: > > Not everyone has GNU's low standards. > > Now may be a good time to remind us of the GNU Kind Communications Guideline; > see . Let's not

Re: reclaiming memory before exit

On 5/14/20 5:11 PM, Jeffrey Walton wrote: > Not everyone has GNU's low standards. Now may be a good time to remind us of the GNU Kind Communications Guideline; see . Let's not let honest technical disagreements degenerate into name-calling.

Re: gcc -fanalyze

On 5/14/20 1:34 AM, Kamil Dudka wrote: > Now I see that we can just > build coreutils with -Dlint even for binary RPMs without any drawbacks. Good, and that also means you don't need the coreutils-8.32-if-lint.patch that you mentioned earlier. One less thing to maintain. > Such a program can

Re: reclaiming memory before exit

On Thu, May 14, 2020 at 8:00 PM Bruno Haible wrote: > > Jeffrey Walton wrote: > > > Building RPMs with -Dlint would mean performance > > > penalty because some programs (e.g. sort) would explicitly release complex > > > data structures just before exit, which is wasteful. > > > > I think it may

Re: reclaiming memory before exit

Jeffrey Walton wrote: > > Building RPMs with -Dlint would mean performance > > penalty because some programs (e.g. sort) would explicitly release complex > > data structures just before exit, which is wasteful. > > I think it may be a bit presumptuous to call cleanup wasteful. > > Proper cleanup

Re: c-stack.c and DEBUG: missing import

Hi Bruno, there is one more issue with c-stack when all warnings are enabled (and the DEBUG flag is set): c-stack.c: In function ‘segv_handler’: c-stack.c:175:5: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result] 175 | write

Re: gcc -fanalyze

On Thursday, May 14, 2020 6:23:19 AM CEST Paul Eggert wrote: > I doubt whether anybody will care about that "waste"; it's just a few > instructions. Good point. I did not look at what merge_tree_destroy() and queue_destroy() really do and thought that their complexity was O(n). Now I see that