Talk:C dynamic memory allocation

message: Hello fellow Wikipedians,
I have just modified  on C dynamic memory allocation. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit User:Cyberpower678/FaQs#InternetArchiveBot*this simple FaQ for additional information. I made the following changes:
*Added archive http://web.archive.org/web/20090122071923/http://www.phrack.org:80/issues.html?issue=57&id=8&mode=txt to http://phrack.org/issues.html?issue=57&id=8&mode=txt
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at ).
Cheers.—cyberbot IITalk to my owner:Online 23:40, 1 June 2016 (UTC)
replies: text: Sunmist3 (talk) 22:00, 6 July 2016 (UTC)
thread_title:  External links modified 

message: Hello fellow Wikipedians,
I have just modified one external link on C dynamic memory allocation. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20060409094110/http://www.osdcom.info/content/view/31/39/ to http://www.osdcom.info/content/view/31/39/
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 20:14, 28 July 2017 (UTC)
thread_title:  External links modified 

message: Neither C90 nor C99 nor C11 nor C18 appear to indicate that there is a given region containing all memory allocated by , , , or .  For example, an implementation could, conceivably, allocate objects larger than the page size used by the OS from one region of the address space, by rounding up the size to a multiple of a page size and allocating  n/page_size pages aligned on a page boundary, and could allocate smaller objects from a separate pool of memory.  (If I remember correctly, the Darwin memory allocator works that way.)
So allocating from a "heap" is best thought of as meaning "these allocations come from one or more places, and all of those places, considered together, constitute a 'heap'".
Note also that none of those standards use the term "heap".
(The term "heap" predates both C and Unix; it dates back at least as far as Algol 68, the Report for which says, in section 5.2.2 "Generators", that
In an answer to a StackOverflow question "What is the origin of the term 'heap' for the free store?", somebody notes that even K&R, Second Edition, didn't use the term "heap":
So perhaps neither "free store" nor "freestore" nor "heap" should be used here, as this is about C.
As for C++, C++2017 uses the phrase "free store" in three places:
* on page 1, it says "In addition to the facilities provided by C, C++ provides additional data types, classes, templates, exceptions, namespaces, operator overloading, function name overloading, references, free store management operators, and additional library facilities.", where I assume "free store management operators" means  and ;
* section 15.5 "Free store", on pages 289 to 291, uses it in the section title but doesn't seem to say what "free store" is;
* the index has, on page 1518, an entry "free store, see also , , 289".
So I'm not even sure what should be said about C++.
(Darwin also offers a set of "zone" routines that take a  as an argument, where a "zone" is allocated with  and destroyed, along with everything allocated in it, with .   returns the zone from which  etc. allocate memory, so, at least on Darwin, I guess you could say that stuff is allocated from a "zone".
However, none of that is a reason to use "zone" here, unless it's commonly used in platforms that aren't Darwin-based.) Guy Harris (talk) 06:29, 27 July 2022 (UTC)
thread_title:  "heap", "free store", etc. 

message: The article says that glibc limits allocation up to 2^(CHAR_BIT * sizeof(ptrdiff_t) - 1) - 1 . This is a compiler limitation,  GCC generates non-sense (by design cannot deal with objects bigger than ptrdiff_t) for any allocation over that value, clang DCEs the code because "it can never  succeed".. 181.160.10.238 (talk) 22:23, 4 October 2023 (UTC)
thread_title:  It is the compiler not glibc