src/lib/libc/stdlib, branch release/5.2.1

Remove malloc debugging for the release.

2003-12-07T04:12:46Z

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

Improve the performance of radixsort() when

2003-11-11T04:59:23Z

sorting strings with common prefixes by noting when all the strings land in just one bin. Testing shows significant speedups (on the order of 30%) on strings with common prefixes and no slowdowns on any of my test cases. Submitted by: Markus Bjartveit Kruger PR: 58860 Approved by: gordon (mentor)

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

Remove incomplete support for running FreeBSD userland on old NetBSD kernels

2003-10-29T10:45:01Z

lacking the issetugid() and utrace() syscalls.

Don peril sensitive (ie: bikeshed sensitive) sunglasses and quietly

2003-10-28T22:36:54Z

send strhash(3) off to sleep with the fishes. Nothing in our tree uses it. It has no documentation. It is nonstandard and in spite of the filename strhash.c and strhash.h, it lives in application namespace by providing compulsory global symbols hash_create()/hash_destroy()/hash_search()/ hash_traverse()/hash_purge()/hash_stats() regardless of whether you #include or not. If it turns out that there is a huge application for this after all, I can repocopy it somewhere safer and we can revive it elsewhere. But please, not in libc!

Consistently cast to (u_char *) when filling with junk.

2003-10-25T23:47:33Z

Style changes. Inching closer to convergence with OpenBSD.

2003-10-25T12:56:51Z

Cite the published version of "Engineering a Sort Function" instead of

2003-09-30T07:05:46Z

an email address. Spell McIlroy correctly.

More style fixes to improve diffability with OpenBSD.

2003-09-27T18:58:26Z

Pull 'A' evilness for realloc(3) from OpenBSD.