Talk:C dynamic memory allocation/Archive 2: Difference between revisions

Revision as of 01:30, 29 May 2015

Revision as of 00:56, 2 June 2016

Line 52:

: I don't think there was a consensus to move the article to this particular title (which sounds rather awful to me), but there does seem to be support to move it to ''some'' title that indicates this articles has a broader than just the <code>malloc</code> function. I would have to agree with the latter. It's would seem quite to write an ''encyclopedic'' article on just the <code>malloc</code> function, you would quickly start discussing at least <code>free</code> and <code>realloc</code> and related functions, such as <code>alloca</code>. Instead of arguing if there was a consensus or not, it might be more constructive to open a [[WP:RM]] on this page. —''[[User:Ruud Koot|Ruud]]'' 13:26, 24 October 2011 (UTC)

:: Is there really a need to open [[WP:RM]]? We wouldn't move the page back to ''malloc'' in any case, because of lack of support for that. As for moving to a similar page, I agree that the current title is somewhat ugly, but I've yet to see a proposal for a better title. By the way, the correct title probably would be ''C memory management functions'', because that's what the C standard uses (section 7.20.3). [[User:1exec1|1exec1]] ([[User talk:1exec1|talk]]) 23:06, 25 October 2011 (UTC)

== Proposal to split ==

I agreed with Christian75's [http://en.wikipedia.org/w/index.php?title=C_dynamic_memory_allocation&curid=384289&diff=457860413&oldid=457265015 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 [[WP:OR|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 [[WP:!VOTE|!votes]], seeking consensus. [[User:Msnicki|Msnicki]] ([[User talk: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. [[User:1exec1|1exec1]] ([[User talk: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 &ndash; 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 &ndash; main memory allocator"''. Even before the invention of the modern notion and terminology of [[Class (computer programming)|classes]], it was certainly understood that some things only made sense grouped together. [[User:Msnicki|Msnicki]] ([[User talk: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. [[User:1exec1|1exec1]] ([[User talk: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. [[User:1exec1|1exec1]] ([[User talk: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.<br> 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. [[User:Msnicki|Msnicki]] ([[User talk: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.[[User:1exec1|1exec1]] ([[User talk: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 &ndash; A Storage Allocator"'', they present a more serious one implementing (pp. 174&ndash;177) <code>alloc</code>, <code>morecore</code> (which calls the Unix sbrk system call) and <code>free</code>. On page 175, they remark, "The function <code>morecore</code> obtains storage from the operating system. The details of how this is done of course vary from system to system."<br>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."<br>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&ndash;188, explaining how it was done. [[User:Msnicki|Msnicki]] ([[User talk: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. [[User:1exec1|1exec1]] ([[User talk: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 [http://minnie.tuhs.org/cgi-bin/utree.pl The Unix Tree]. The earliest I could find was dmr's [http://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/dmr/malloc.c Fourth Edition malloc.c], dated 8-31-1973. The [http://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/source/s4/malloc.c PWB1 malloc.c], dated 2-10-1980, implemented the whole memory allocator, including free, but realloc was separately compiled as [http://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/source/s4/realloc.c realloc.c], so that if you didn't actually need those bytes of code, they wouldn't be linked in. In the [http://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/lib/libc/vax/gen/malloc.c System III malloc.c], dated 4-11-1980, and the [http://minnie.tuhs.org/cgi-bin/utree.pl?file=Ultrix-3.1/src/libc/gen/malloc.c Ultrix 3.1 malloc.c], dated 4-22-1986, realloc is part of malloc.c. You can compare those mallocs to the [http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD/usr/src/lib/libc/gen/malloc.c 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. [[User:Msnicki|Msnicki]] ([[User talk:Msnicki|talk]]) 17:57, 30 October 2011 (UTC)