Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
What is malloc's standard-defined behavior with respect to the amount of memory it allocates?
I recently told a friend that malloc(n) allocates and returns a pointer to a block of at least N bytes of memory, as opposed to exactly N; that it is allowed to allocate 'extra' memory to meet e.g. alignment requirements.
He asked what the C standard had to say about this behaviour. I wasn't sure, so I looked it up, and...I can't find any explicit statement on the subject.
Did I miss something in the standard, or was I wrong to begin with? What is malloc's standard-defined behaviour with respect to the block of memory it returns?
(this discussion was in the context of a single-byte buffer-overrun bug that only manifested when N was a multiple of 8; it certainly looked like malloc was rounding up to the word size, although obviously trying to use any such slop is still a bug)
2 answers
You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.
Here's a relevant bit from the standard (C89, section 7.20.3):
The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object and then used to access such an object or an array of such objects in the space allocated
In other words, the compiler/library has to ensure that the pointer that malloc returns is aligned to whatever alignment requirements the current platform has. If your platform requires 32-bit I/O to be aligned to 4-byte boundaries, then malloc is going to give you a pointer that's aligned to a 4-byte boundary. The pointer has to work with "any type" of object (since you can't pass type information to malloc), so that means it will be aligned to whatever the strictest boundary for your platform is. In a lot of cases this corresponds to the word size of the machine.
In your specific case, you only saw the problem when N was a multiple of 8. Most likely, your platform's alignment rules required malloc to return pointers aligned to 8-byte boundaries. When your allocation wasn't a multiple of 8 bytes, the size % 8 bytes of space between the end of your buffer and the next 8-byte boundary were unused. You could write into these bytes because there was no way for malloc to allocate them for someone else without generating a pointer that didn't meet the requirement above. When N is indeed a multiple of 8, then the very next byte after the array is allocatable, and writing into it risks overwriting someone else's memory. An interesting side effect is that code that appears to work on your machine might not work on a hardware platform that has different alignment requirements.
Since accessing the memory allocated by malloc beyond the size given to the call is undefined behaviour (which means that the standard poses no restriction to the behaviour of a program that does this), and since there's no standard way to determine the length of the allocated block, malloc is indeed allowed to allocate more memory, since there is no standard conforming way for a program to determine whether the allocation was larger than requested.
Note that the standard does not need to give explicit permission for the compiler/standard library to do so, since it already has implicitly given permission by declaring access of that memory as undefined behaviour.
0 comment threads