6 commits

Author	SHA1	Message	Date
Jason Evans	044047fae1	Remove fragile xallocx() test case. ... In addition to depending on map coalescing, the test depended on munmap() being disabled so that chunk recycling would always succeed.	2015-09-24 19:52:28 -07:00
Jason Evans	d260f442ce	Fix xallocx(..., MALLOCX_ZERO) bugs. ... Zero all trailing bytes of large allocations when --enable-cache-oblivious configure option is enabled. This regression was introduced by 8a03cf039c (Implement cache index randomization for large allocations.). Zero trailing bytes of huge allocations when resizing from/to a size class that is not a multiple of the chunk size.	2015-09-24 16:38:45 -07:00
Jason Evans	65b940a3c5	Loosen expected xallocx() results. ... Systems that do not support chunk split/merge cannot shrink/grow huge allocations in place.	2015-09-15 15:48:42 -07:00
Jason Evans	aca490f004	Add more xallocx() overflow tests.	2015-09-15 14:39:29 -07:00
Jason Evans	560a4e1e01	Fix xallocx() bugs. ... Fix xallocx() bugs related to the 'extra' parameter when specified as non-zero.	2015-09-11 20:40:34 -07:00
Jason Evans	d82a5e6a34	Implement the *allocx() API. ... Implement the *allocx() API, which is a successor to the *allocm() API. The *allocx() functions are slightly simpler to use because they have fewer parameters, they directly return the results of primary interest, and mallocx()/rallocx() avoid the strict aliasing pitfall that allocm()/rallocx() share with posix_memalign(). The following code violates strict aliasing rules: foo_t *foo; allocm((void **)&foo, NULL, 42, 0); whereas the following is safe: foo_t *foo; void *p; allocm(&p, NULL, 42, 0); foo = (foo_t *)p; mallocx() does not have this problem: foo_t *foo = (foo_t *)mallocx(42, 0);	2013-12-12 22:35:52 -08:00