Talk:C dynamic memory allocation

Template:IEP assignment

Proposal to split

I agreed with Christian75's edit summary, ""C dynamic memory allocation" - so broad term that it isnt just the C standard library". I think culling out a lot of the junk in this article, especially all those horrid code examples, had made for a much better article about malloc. But I also think that with the new title, that the article is now one article about two different things. Starting at C dynamic memory allocation, where you get told about the 4 basic CRTL functions in the family, I think this is a pretty good article about malloc, comparable to the one about new (C++).

But everything before that seems to be about something else and right now, I'm not exactly sure what that is. I'm a little concerned that it may be original research, though I concede it may be premature to judge how the article might develop. But I don't think it should be part of an article about malloc. Splitting it, restoring a separate article on malloc makes that information more accessible to programmers and others who know what malloc means and may search on it, but aren't sure what C dynamic memory allocation means. I request !votes, seeking consensus. Msnicki (talk) 19:46, 28 October 2011 (UTC)

Comment. I think that malloc can't be described without taking into account free, so we would end up with an article about two functions anyway. I agree that a separate article about malloc would be better for accesibility for those who know 'malloc' but not 'C dynamic memory allocation', however malloc already redirects here, so anyone who searches for malloc ends up in this article. Regarding the scope problem ("C dynamic memory allocation" - so broad term that it isnt just the C standard library"), the intent was to describe dynamic allocation functions in the C standard library. Maybe C standard memory allocation functions would be a more descriptive title. 1exec1 (talk) 09:25, 29 October 2011 (UTC)

Unix programming docs have traditionally lumped the 4 basic functions together on one page as malloc because they all manipulate the same shared data structures and resources. In the BSD 4.3 UNIX Programmer's Manual Reference Guide, dated May 14, 1986, there is a single MALLOC(3) page for "malloc, free, realloc, calloc, alloca – memory allocator"; there is no separate page for free. In the AT&T UNIX System V Release 2 Programmer's Reference Manual, (c) 1985, it's the same idea: That manual also had only a single MALLOC(3C) page for "malloc, free, realloc, calloc – main memory allocator". Even before the invention of the modern notion and terminology of classes, it was certainly understood that some things only made sense grouped together. Msnicki (talk) 17:30, 29 October 2011 (UTC)

Well, Wikipedia has its own article naming guidelines which say that the title of the article must represent the content. We would group malloc, free, calloc and realloc together so the article could not be named "malloc". In any case, the split is also not possible because we don't have enough content. 1exec1 (talk) 17:56, 29 October 2011 (UTC)

Oppose. The title of the new article (malloc) would not represent the content, since it the page would contain four functions. Furthermore we don't have enough content to warrant the split. 1exec1 (talk) 17:57, 29 October 2011 (UTC)

Okay, then how about just moving it back to the old title if, apart from a discussion of malloc, there's really nothing else to write about.
There's nothing unusual about giving an interface a name matching the most significant exposed property or entry point, c.f., new (C++), which also discusses delete. In the case at hand, malloc itself is actually the only essential feature because you could either recreate or live without the others. It's the one that gave you more memory. It's certainly no trick to zero memory and get calloc. And lots of apps only allocate and never free anything until they exit. realloc is even rarer. But if you needed to recreate free, it's not been a secret how to do that. In the 70s, PL/I programmers discovered that if they were going to need to allocate and free the same size structures repeatedly, it was cheaper to save them on a free list and check there for an item of the same type before going back to the OS. To do something better than that, you need to be able to coalesce the frees, which is (ta-da) pretty much what the malloc "memory allocator" code did. This is why this was known as malloc, not malloc et al or something else. Msnicki (talk) 15:25, 30 October 2011 (UTC)

I think that the previous discussion clearly shows that there is little support for malloc. In any case, I did some searching for WP:RS and most of them (including the C and C++ standards and K&R The C programming language) use variants of memory management to refer to all four functions.1exec1 (talk) 18:09, 30 October 2011 (UTC)

K&R were vague about memory allocation because, in the first edition in 1978, they were talking about the language and they weren't at all sure how'd you'd do memory allocation on your machine, or if you even knew how. There is no mention of malloc anywhere in that edition. Instead, they tell you how to build your own. The first, page 95, is quite simple-minded, allocating from a static character array. In chapter "8.7 Example – A Storage Allocator", they present a more serious one implementing (pp. 174–177) alloc, morecore (which calls the Unix sbrk system call) and free. On page 175, they remark, "The function morecore obtains storage from the operating system. The details of how this is done of course vary from system to system."
This was 3 years before the IBM PC and even after PCs arrived, Unix was still confined to minicomputers and high end workstations like the Sun well into the mid- to late-80s because PCs were too slow and couldn't support enough memory. In 1978, when Kernighan and Ritchie were writing their book, if you were running Unix, it was probably on a PDP-11 in a lab or at a university and you got the source on a paper tape. But there was an even better chance that you only got the compiler and you were on a mainframe, "For example, on the IBM 360/370, the Honeywell 6000, and many other machines."
By the second edition of the book in 1988, a lot had changed! Everyone did have malloc and it made sense to call it in that their revised example, pp. 186–188, explaining how it was done. Msnicki (talk) 00:16, 31 October 2011 (UTC)

I'm not sure how this relates to the discussion. The second version of K&R includes §7.8.5 Storage Management at p.136 which talks about malloc, calloc, realloc and free. You still haven't addressed my previous point. 1exec1 (talk) 23:47, 1 November 2011 (UTC)

• Comment. In case anyone's curious to see them, here are some links to archival snapshots of malloc at The Unix Tree. The earliest I could find was dmr's Fourth Edition malloc.c, dated 8-31-1973. The PWB1 malloc.c, dated 2-10-1980, implemented the whole memory allocator, including free, but realloc was separately compiled as realloc.c, so that if you didn't actually need those bytes of code, they wouldn't be linked in. In the System III malloc.c, dated 4-11-1980, and the Ultrix 3.1 malloc.c, dated 4-22-1986, realloc is part of malloc.c. You can compare those mallocs to the BSD4.3 malloc.c, dated 3-9-1986. The BSD malloc does not do coalescing; instead, it just uses a small number of lists of fixed sized blocks (analogous to the strategy I mentioned PL/I programmers used to use.) The Bell Labs mallocs all did coalescing. Msnicki (talk) 17:57, 30 October 2011 (UTC)

Move discussion in progress

There is a move discussion in progress which affects this page. Please participate at Talk:C standard library - Requested move and not in this talk page section. Thank you. —RM bot 09:40, 8 November 2011 (UTC)

Can we take the "not casting is important because you might have not included stdlib.h" argument...

out behind the woodshed and shoot it please? Every time I see it (not just on Wikipedia) I want to slap someone. - Richfife (talk) 08:02, 30 January 2013 (UTC)

reallocarray

We should probably have a mention of OpenBSD's relatively recent reallocarray[1] interface here, too, but I'm not an expert on the history of and variations between the various C library versions, so I'm not the best person to add this to the article. -- The Anome (talk) 09:04, 21 October 2014 (UTC)

segmentation fault

"usually causes a segmentation fault" sounds like a PDP-11 or UNIX term. It will be called other things on other machines and OSs. Like Memory Access Violation. In embedded systems, it may not cause a trap at all.

But expect a program crash. Wmdgus73 (talk) 19:55, 28 May 2015 (UTC)

External links modified

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:

• 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 {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• 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 II}_{Talk to my owner:Online} 23:40, 1 June 2016 (UTC)