cmemorymemory-managementallocatorsbrk

Are padding bytes considered allocated or unallocated in a memory allocator?


I am writing a custom memory allocator in my program and trying to better understand what is considered allocated vs unallocated memory. I am told that for a basic, "naive" sbrk() memory allocator, calls to sbrk() must provide a size aligned to (a multiple of) 16 bytes. This means that if I need to allocate for example, 5 bytes of memory, the operation (5 + (16-1)) & ~(16-1)) is applied, which rounds up to 16 in this case. If the size requested were 17 instead of 5, then it would round to 32.

This means that we are getting back from the operating system more bytes than the user requested for the sake of alignment. My question is, are the 11 bytes (in the case of the first example) or 15 bytes (in the case of the second example) considered "allocated" or not? In a proper implementation of a memory allocator, could the user actually use more than the requested bytes between the requested size and the 16 byte boundary? If not, how is this enforced?


Solution

  • My question is, are the 11 bytes (in the case of the first example) or 15 bytes (in the case of the second example) considered "allocated" or not?

    No, they are not considered allocated. To be more specific, those bytes are not owned by the user's program, they are owned by the memory allocator.

    In a proper implementation of a memory allocator, could the user actually use more than the requested bytes between the requested size and the 16 byte boundary?

    No, the user's program is only allowed to use the memory that was requested.

    If not, how is this enforced?

    It's not enforced. That's something that sets C apart from other languages. C has lots of rules, but it doesn't enforce them. The programmer must understand the rules, and follow the rules. If the programmer does not follow the rules, the result is undefined behavior. See also this post. In the words of the C specification (emphasis added):

    Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).