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.

Comments on What is malloc's standard-defined behavior with respect to the amount of memory it allocates?

Parent

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 attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

0 comment threads

Post
+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 attention from curators or moderators?
You might want to add some details to your flag.

1 comment thread

I don't think this is correct (2 comments)
I don't think this is correct
Lundin‭ wrote almost 3 years ago

I don't think this is correct - see the quote in my posted answer. Also the memory returned by malloc does not have a declared or effective type, so normal array out of bounds rules do not apply, at least not until it gets an effective type.

celtschk‭ wrote almost 3 years ago

Lundin‭ The alignment requirement just tells you where the allocated memory has to start, the end of the allocation does not need to be aligned. The implementation would be allowed to use the very next byte after the allocation for its own purposes, independent of its alignment. Or if the platform allows byte-level access control (IIRC, with 80286 protected mode you could set the length of a segment to the byte), it can make the very next byte inaccessible.

Note however that even if the following bytes up to the next alignment boundary are neither used for something else nor protected against access, that still doesn't imply that access to those bytes is defined behaviour. Note that the range of undefined behaviour also includes “works as expected” (and also, “works as expected in all tests, but fails spectacularly once deployed”).