Jump to content

Talk:C dynamic memory allocation

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
(Redirected from Talk:Malloc)

[edit]

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 User:Cyberpower678/FaQs#InternetArchiveBot*this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

checkY An editor has reviewed this edit and fixed any errors that were found.

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—cyberbot IITalk to my owner:Online 23:40, 1 June 2016 (UTC)[reply]

Sunmist3 (talk) 22:00, 6 July 2016 (UTC)[reply]
[edit]

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:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

checkY An editor has reviewed this edit and fixed any errors that were found.

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 20:14, 28 July 2017 (UTC)[reply]

"heap", "free store", etc.

[edit]

Neither C90 nor C99 nor C11 nor C18 appear to indicate that there is a given region containing all memory allocated by malloc(), calloc(), realloc(), or aligned_alloc(). 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

The use of a local-generator implies (with most implementations) the reservation of storage on a run-time stack, whereas heap-generators imply the reservation of storage in another region, termed the "heap", in which garbage-collection techniques may be used for storage retrieval. Since this is less efficient, local-generators are preferable; this is why only LOC may be omitted from sample-generators of variable-declarations.

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":

N.B. I don't think it's right to blame C, as neither K&R (2nd Ed) nor the C standard say "heap" anywhere. The C++ standard only uses heap to mean the data structure, and refers to the source of dynamic memory as "the freestore".

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 new and delete;
  • 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 new, delete, 289".

So I'm not even sure what should be said about C++.

(Darwin also offers a set of "zone" routines that take a malloc_zone_t * as an argument, where a "zone" is allocated with malloc_create_zone() and destroyed, along with everything allocated in it, with malloc_destroy_zone(). malloc_default_zone() returns the zone from which malloc() 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)[reply]

India Education Program course assignment

[edit]

This article was the subject of an educational assignment supported by Wikipedia Ambassadors through the India Education Program.

The above message was substituted from {{IEP assignment}} by PrimeBOT (talk) on 19:56, 1 February 2023 (UTC)[reply]

It is the compiler not glibc

[edit]

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)[reply]

Retrieved from "https://wiki.riteme.site/w/index.php?title=Talk:C_dynamic_memory_allocation&oldid=1256080520"