On Tue, Nov 07, 2000 at 12:09:09AM -0800, Lyle Coder wrote:
> When a program does a malloc... the glibc gets atleast on page (brk)
> [actually, glibs determins of it needs to brk more memory from the kernel...
> because it maintains it;s own pool].. so if you malloc 4 byts, you can copy
> to that pointer more than 4 bytes (upto a page size, ex 4K)... hope that
> answers one of your questions... as far as why malloc(0) works... I dunno
Maybe following extract from glibc's malloc/malloc.c beginning
comments can help you there:
Minimum overhead per allocated chunk: 4 or 8 bytes
Each malloced chunk has a hidden overhead of 4 bytes holding size
and status information.
Minimum allocated size: 4-byte ptrs: 16 bytes (including 4 overhead)
8-byte ptrs: 24/32 bytes (including, 4/8 overhead)
When a chunk is freed, 12 (for 4byte ptrs) or 20 (for 8 byte
ptrs but 4 byte size) or 24 (for 8/8) additional bytes are
needed; 4 (8) for a trailing size field
and 8 (16) bytes for free list pointers. Thus, the minimum
allocatable size is 16/24/32 bytes.
Even a request for zero bytes (i.e., malloc(0)) returns a
pointer to something of the minimum allocatable size.
Maximum allocated size: 4-byte size_t: 2^31 - 8 bytes
8-byte size_t: 2^63 - 16 bytes
Other systems (malloc libraries) may have different strategies on this
allocation management issue, thus allocating anything smaller than the
needed size is bound to get user burned. malloc(0) is insane thing
(IMO), but at least glibc supports it for some reason. Likely just due
to padding and minimum size issues.
> Best Wishes,
> Lyle
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Nov 07 2000 - 21:00:22 EST