Message-ID: <3EB2F494.5CDF344B@yahoo.com> Date: Fri, 02 May 2003 18:43:32 -0400 From: CBFalconer Organization: Ched Research X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: djgpp-workers AT delorie DOT com Subject: Re: nmalloc documentation revisions References: <3EAF5020 DOT 9E3C6C9A AT yahoo DOT com> <7458-Wed30Apr2003210444+0300-eliz AT elta DOT co DOT il> <3EB08219 DOT 3D55D32A AT yahoo DOT com> <3EB1555C DOT D52AC0B6 AT yahoo DOT com> <3EB2B5C0 DOT 987AC700 AT yahoo DOT com> <2110-Sat03May2003004811+0300-eliz AT elta DOT co DOT il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Eli Zaretskii wrote: > > > Date: Fri, 02 May 2003 14:15:28 -0400 > > From: CBFalconer > > > > On looking things over, I think that the test for oversize > > allocations should also be done for realloc, and that the > > malloc_fail hook should also be called for realloc_failure. The > > hook can tell the difference by the non-NULLness of ptr. > > In the old malloc, realloc always called malloc whenever the > allocation was about to grow, and so these tests were not required in > realloc as malloc would do that anyway. If your code can grow an > allocation without calling malloc in the process, malloc_fail hook > should indeed be called in realloc, and likewise for the > preposterously large allocations. Ok, a minor revision. I reject allocation requests for anything over (INT_MAX-65536). Yes, realloc grows without calling malloc. It goes to lengths to avoid moving any data, which seems to work about half the time or more. Failing that it attempts to expand to free space adjacent below. The only case where realloc calls malloc is realloc(NULL, size). So realloc should be quite efficient in the wild. -- Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT worldnet DOT att DOT net) Available for consulting/temporary embedded and systems. USE worldnet address!