| This is an
archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the
current talk page. |
- 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)
- 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)
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)
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)
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)
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)
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)
"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)