Path: csiph.com!news.swapon.de!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: mergesort code segfaulting on smallish arrays Date: Thu, 07 Nov 2019 10:37:34 -0800 Organization: None to speak of Lines: 27 Message-ID: References: <0ee77699-6964-4782-928b-5e5cdfc714db@googlegroups.com> <1JXwF.50019$kt1.13739@fx46.iad> <396da436-1cc5-4294-b284-1262c1846e22@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="fdd2727d9421cbcb7e0942d3891e7ce6"; logging-data="14471"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19J7OsfhqtsaPVMl2ibqVWd" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:gk28Gi4jVwChVHclfAp6v20Psxk= sha1:hEgrJZrmKsYjj91M8FpqSLVjqMY= Xref: csiph.com comp.lang.c:147737 DFS writes: > On 11/7/2019 11:41 AM, Malcolm McLean wrote: [...] >> You also need to free the arrays, or you get a memory leak. > > I put 2 free()s at the end of merge, but it slowed the program down > significantly. What's the worst that could happen to the program if you > don't free them? The sort always seemed to work fine without them. In your case, the program terminates, and all malloc'ed memory is almost certain to be freed automatically (and possibly more efficiently, since the system can just deallocate the entire heap without worrying about individual objects) If you were going to incorporate your merge() function into a larger program where it might be called multiple times, you'd definitely want to free all your allocated memory. And doing so even in the trivial cases is probably a good habit. How much did it slow down when you added the free()s? [...] -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */