src-test2/lib/libc/stdlib/malloc.c, branch release/6.0.0_cvs

This commit was manufactured by cvs2svn to create tag

2005-11-03T00:35:26Z

'RELENG_6_0_0_RELEASE'. This commit was manufactured to restore the state of the 6.0-RELEASE image.

Take a step closer to the release and turn off malloc debugging.

2005-09-18T03:45:24Z

Approved by: re (implicit)

Remove the check about whether MALLOC_EXTRA_SANITY is defined,

2005-02-27T17:16:16Z

surrounding the undef'ing it. It does not seem necessary to undef some symbol that is not exist, and gcc does not complain about whether a symbol is exist before #undef'ing it out. Spotted by: mingyanguo via ChinaUnix.net forum Reviewed by: phk

Consistently use inline instead of inline__ as the former is an empty macro

2004-07-04T16:11:03Z

in for compilers without support for inline.

Define malloc_pageshift and malloc_minsize for arm.

2004-05-14T11:50:51Z

Rearrange (centralize) initialization of mallocs internals to always be

2004-03-07T20:41:27Z

done before the first call, even if this is a malloc(0) call. PR: 62859

Remove the triplicity in the public functions by vectoring them all

2004-02-21T09:14:38Z

through a realloc like function. Make the malloc_active variable a local static to this new function. Don't warn about recursion more than once per base call. constify malloc_func.

Move the check for sensitive processes to the point where the exception

2004-02-21T08:55:38Z

has been hit, this makes it cover more cases. Call the message function directly rather than fiddle with flag-saving when we find an unknown character in our options. The 'A' flag should not trigger on legal out of memory conditions.

Do not adjust to the pagesize at runtime. Besides for the one-time

2003-11-28T18:03:22Z

initialization overhead, there's a problem in that we never call imalloc() and thus malloc_init() for zero-sized allocations. As a result, malloc(0) returns NULL when it's the first or only malloc in the program. Any non-zero allocation will initialize the malloc code with the side-effect that subsequent zero-sized allocations return a non-NULL pointer. This is because the pointer we return for zero- sized allocations is calculated from malloc_pageshift, which needs to be initialized at runtime on ia64. The result of the inconsistent behaviour described above is that configure scripts failed the test for a GNU compatible malloc. This resulted in a lot of broken ports. Other, even simpler, solutions were possible as well: 1. initialize malloc_pageshift with some non-zero value (say 13 for 8KB pages) and keep the runtime adjustment. 2. Stop using malloc_pageshift to calculate ZEROSIZEPTR. Removal of the runtime adjustment was chosen because then ia64 is the same as any other platform. It is not to say that using a page size obtained at runtime is bad per se. It's that there's currently a high level of gratuity for its existence and the moment it causes problems is the moment you need to get rid of it. Hence, it's not unthinkable that this commit is (partially) reverted some time in the future when we do have a good reason for it and a good way to achieve it. Approved by: re@ (rwatson) Reported by: kris (portmgr@) -- may the ports be with you

Externalize malloc's spinlock so that a thread library can take

2003-11-04T19:49:56Z

it around an application's fork() call. Our new thread libraries (libthr, libpthread) can now have threads running while another thread calls fork(). In this case, it is possible for malloc to be left in an inconsistent state in the child. Our thread libraries, libpthread in particular, need to use malloc internally after a fork (in the child). Reviewed by: davidxu