Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

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?

+11
−0

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)

History
Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

0 comment threads

2 answers

+8
−0

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.

History
Why does this post require moderator attention?
You might want to add some details to your flag.

1 comment thread

I don't think this is correct (2 comments)
+1
−0

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.

History
Why does this post require moderator attention?
You might want to add some details to your flag.

1 comment thread

Don't assume anything about usage of bytes after the malloc'ed bytes (1 comment)

Sign up to answer this question »