Talk:C dynamic memory allocation/Archive 2

Archive 1

Archive 2

Renaming the page to a more general title

Based on talk at Talk:C standard library#Pages for each function and WP:NOTMANUAL

The scope of the article is a lot larger than a single function. The article also covers calloc, free, memset and realloc along with general information on dynamically allocating memory in C. I think moving the article to Dynamic memory management in C and making the necessary changes (redoing the lede, rewording some stuff) is a good first step. C++ adds a lot of complications in addition to new/new[] like smart pointers and destructors so merging that stuff into here should be a separate conversation (I don't think we should). strcat (talk) 05:37, 7 October 2011 (UTC)

I think a better title would be C memory management. It is shorter and consistent with existing C input/output, C string, etc., as well as with Memory management. A page titled Dynamic memory management also exists, but it discuss the same topic, so I proposed it to be merged into Memory management.1exec1 (talk) 20:41, 8 October 2011 (UTC)

alloc.h

I do not think alloc.h can be merged with Memory management page. Memory management page talks about general memory management issues in computer science. On the other hand, alloc.h falls under C library. This is not a standard C header file. This page describes functions in alloc.h briefly and tells about the difference between these functions and general C functions. Hence, according to C header category, in my opinion, alloc.h can not be merged with Memory management.AshishDandekar7 (talk) 02:36, 5 October 2011 (UTC)

Well, alloc.h is actually a good example of page that we want to avoid. The content is not notable and fails WP:NOTMANUAL, i.e. most of the content is usable only for a programmer. Having said that, I think we can find a solution that is acceptable for you. I see that you participate in an ongoing project in which most of the pages we are going to merge are assigned as homeworks. We can wait until the deadline (October 25th) for these homeworks passes and to apply our changes after that. What do you think?1exec1 (talk) 11:38, 5 October 2011 (UTC)

I am fine with your proposal. But I am not understanding clearly, why Wikipedia can not have technical stuff? I have read WP:NOTMANUAL. But I am thinking about its reason.AshishDandekar7 (talk) 07:48, 6 October 2011 (UTC)

Well, technical stuff itself is perfectly legal. However, it matters what the content is. I'm not an expert in wikipedia policies, but it seems wikipedia attitude is that wikipedia is for general public and thus anything that is significant only for very limited group of people should be avoided (thus we have notability criteria). This applies not only to the content itself, but for writing style also, so, for example, it is discouraged to write in very technical (i.e. not understandable for general public) style even in the technical articles. Now, regarding the manuals, what we don't like, is the pages like this, which can be interesting only to a programmer, who is about to use that function. This is pretty much the only problem.1exec1 (talk) 12:12, 7 October 2011 (UTC)

The alloc.h header could at least be mentioned on Memory management, unless there’s a more appropriate topic. (Dynamic memory allocation perhaps?) We can leave the page alloc.h as a redirect that is still a member of Category:C headers if you like; see how the memcmp redirect appears in italics in Category:C standard library.

 The alloca function is probably worth a mention somewhere like Stack-based memory allocation, including its history, problems implementing it and why it is common but isn’t really standardised. The other functions currently tabled should go somewhere common to avoid duplication with malloc. The other bits seem to be only related to special TIGCC functions which are not actually mentioned in the alloc.h page as far as I can see. Vadmium (talk, contribs) 12:53, 5 October 2011 (UTC).

• Oppose rename. I think malloc is and should be a much narrower topic than "memory management" (or variations), even with some discussion of its allied calloc and realloc routines included. Memory management is a very broader term and invites discussion of allocation strategies (best fit, first fit, buddy system, etc., etc.) that most people who only want to know about malloc probably don't care about (precisely because the whole point of malloc is to hide that stuff). Sometimes we'll have somewhat overlapping articles. I don't think that's always terrible. Msnicki (talk) 02:52, 9 October 2011 (UTC)

I disagree. We can divide most of the material in the article into two groups: a) tutorials, examples, basically a manual how to use various functions; b) discussion about different allocation strategies. The content of the former group is forbidden by WP:NOTMANUAL, and in this discussion it was agreed to remove such material. The latter group discusses precisely the same topic, as you agreed memory allocation should discuss, so we can merge the articles.1exec1 (talk) 17:16, 9 October 2011 (UTC)

That's not what I'm proposing. An article about malloc can certainly give an encyclopedic discussion of that topic and that topic only, without turning into a man page. I know what I'd expect to find if I'd heard the term and didn't understand it: I'd expect it to answer the who, what, when, where and why questions to extent any of these was matter in understanding what this is. If I wanted to know more, about how allocation strategies differ and how the algorithms worked, I'd expect that in article about allocation strategies, not right here.
Personally, I do not like the examples in this article. This is way too much WP:HOWTO. I think it's possible to describe software interfaces in an encyclopedic manner but I don't think this is it. Compare the way technical detail is presented here to the way it's done in the C shell article, where all the control structures, etc., are described in fairly complete detail, but it's done conceptually, not with examples. (Proper credit: the format was borrowed from Joy's original paper, "An Introduction to the C shell".) Msnicki (talk) 18:17, 9 October 2011 (UTC)

Argh, I must have confused myself. I am actually against merging with Memory management (see my first comment), but since I am involved in quite a lot of merge discussions, and didn't bother to recheck what I'm arguing for, I managed to find argumentation even for the opposite! LOL.

I agree with your points, there are strong reasons against the merge and even if my above (now deleted) arguments make some sense, they are weak. I was proposing to move the article to C memory management and to merge all articles about this topic to there. What do you think about that?1exec1 (talk) 22:16, 9 October 2011 (UTC)

I agree with you that this article covers a narrower topic than "C memory management" because it focuses specifically on dynamic memory allocation within C. When I proposed the move, I had the move template suggesting a move to Dynamic memory allocation in C (1exec proposed C memory management instead). I think malloc is a reasonable name for the article, but the topic is a bit broader than a specific function from the small family of functions that are used. strcat (talk) 22:29, 9 October 2011 (UTC)

I still disagree with any name change. I don't think there is a valid notable topic in between Malloc and Memory management or Dynamic memory allocation focusing just on C. Malloc is the C run-time library routine. The more general topic of memory management really isn't tied to any particular language, it's about strategies and algorithms that might be employed by the designer of a language, run-time library or OS. I concede that a big problem here is that those other articles are just awful and don't actually talk about strategies and algorithms. But that's a problem for those articles, not this one. Msnicki (talk) 22:54, 9 October 2011 (UTC)

I don't think that this article discusses only Malloc as you seem to allege. If we took it apart and analyzed section by section, you'd see that only small part of the article discusses malloc, the C standard library function:

Rationale - dynamic memory allocation. Discusses rationale for dynamic memory management but not rationale for malloc as a method of dynamic memory allocation

Dynamic memory allocation in C - malloc/free

Usage - malloc

Type safety - malloc

Related functions - calloc, realloc

Common errors - dynamic memory allocation. These problems are inherent to any manual memory management method.

Implementations - dynamic memory allocation. These algorithms can be employed as a backend for almost any memory allocation interface.

1exec1 (talk) 23:33, 9 October 2011 (UTC)

These are problems to be fixed by making this article better. Msnicki (talk) 23:44, 9 October 2011 (UTC)

To me, C memory management could also refer to storage classes in C, static variables, static memory allocation, automatic variables, stack-based memory allocation. I’m thinking this article should perhaps be about dynamic memory allocation in the C standard library, as used by all the functions that return a buffer that has to eventually be passed to free. But that’s rather unweildy; malloc certainly isn’t perfect; maybe Dynamic memory management in C is a compromise; I can’t think of much better :P. Vadmium (talk, contribs) 14:30, 12 October 2011 (UTC).

Hmm, after some thought, I agree that C memory management is too broad. However I find that in C at the end of Dynamic memory management in C somewhat odd, since it breaks consistency with C input/output, C string, C mathematical operations, etc. Maybe we can use C dynamic memory allocation?1exec1 (talk) 18:01, 12 October 2011 (UTC)

C dynamic memory allocation is also a subcategory of C memory management. These files are the outlines of how the dynamic memory allocation is achieved in C. alloc.h is a header file. Header files must have different page because they do not give the concept but the information about the functions and how they work.alloc.h is not telling "what is memory management in C?" but it tells how the memory is managed by using functions in it. So I do think, header files should not be merged.AshishDandekar7 (talk) 06:17, 14 October 2011 (UTC)

No, WP:NOTMANUAL explicitly forbids information about how to use functions, a.k.a. manual. Also, we agreed that we don't want such pages in this discussion. Having said that, the content won't disappear anywhere, since we will import it to Wikibooks before merging. 1exec1 (talk) 11:58, 14 October 2011 (UTC)

No consensus for the rename

There was no consensus to rename this page. None at all. 1exec1 argued endlessly that that's what he wanted to do, but got no clear support from anyone else and a clear objection from me. You can't come in with a proposal for a move and then ignore the fact that no one agrees with you. This should be undone. Msnicki (talk) 14:58, 19 October 2011 (UTC)

Could you point me out how "I think moving the article to Dynamic memory management in C <...>is a good first step" (User:strcat) and "maybe Dynamic memory management in C is a compromise; I can’t think of much better" (User:Vadmium) does not constitute support? By the way, the general consensus against articles for each function in the C standard library was clearly established here 1exec1 (talk) 15:29, 19 October 2011 (UTC)

Those are editors willing to discuss the idea and consider alternatives. Even to the extent they may have been okay with a different title, both of them were thinking of a different title than what you picked. That is not consensus. You did not get consensus. Msnicki (talk) 15:32, 19 October 2011 (UTC)

You seem to misunderstand how WP:CONSENSUS process works. There was a strong consensus against leaving this page at malloc. Having the support for a change, I moved the page to a title, similar to the suggested ones. Now I am further looking for refinements. This is how the consensus works, see WP:CONSENSUS, specifically "the absence of a prior discussion does not prove that the change is not supported by consensus", in this case, absence of prior discussion about the exact title does not prove that I did not have consensus.1exec1 (talk) 15:43, 19 October 2011 (UTC)

There's no reason to make this personal. I think I understand consensus just fine. You didn't get one. But let's let others weigh in. Msnicki (talk) 15:51, 19 October 2011 (UTC)

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 malloc function. I would have to agree with the latter. It's would seem quite to write an encyclopedic article on just the malloc function, you would quickly start discussing at least free and realloc and related functions, such as alloca. Instead of arguing if there was a consensus or not, it might be more constructive to open a WP:RM on this page. —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). 1exec1 (talk) 23:06, 25 October 2011 (UTC)

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)