Talk:Malloc

From Wikipedia, the free encyclopedia

You have new messages (last change).

In all actuality, I've solved the heap problem for glibc on Linux, in theory; but I can't bring myself to write a "Hybrid allocator" section with an explaination. I'm currently trying to get the glibc people to adopt the design and code it, but they haven't responded to me yet.

The reason why I won't write the section is because I'm a source of bias. Until I get the thing accepted, my only reasoning for putting it on there could be that I'm trying to draw attention to the idea; however, it may be useful to draw attention to it, as others may benefit from the concept. So, if anyone wants me to write a section on it, I will, by request only.


requests+++

Contents

[edit] Pointers vs. arrays

Pointers and arrays are not the same in C; malloc returns a pointer to an allocated region of memory, it does not return an array (or a pointer to the beginning of an array, or anything else). The article confused this in a few places. See here and here for more information. Neilc 18:12, 27 Mar 2005 (UTC)

Pointers are not the same as declared arrays, but a pointer can be used in place of an array name. I don't know about recent compilers, but back in the 80's, the compiler took any array notation and converted it to pointer notation. wrp103 (Bill Pringle) - Talk 14:23, 29 Mar 2005 (UTC)
I don't disagree that in some situations pointer notation and array notation are equivalent in C -- that is pretty elementary. That doesn't change the fact they are two distinct concepts, however. Furthermore, it is not true that the compiler will generate identical addressing code for an array and a pointer -- there is an extra level of indirection involved in accessing a pointer. For example, this program will dump core:
/* File 1 */
#include <stdio.h>
extern char *declared_as_ptr;

int main(void)
{
        printf("ptr = %s\n", declared_as_ptr);
        return 0;
}

/* File 2 */
char declared_as_ptr[] = "xxx";
The pages I linked to originally have more information on this. Neilc 15:49, 29 Mar 2005 (UTC)

[edit] Terminating Zero

A terminating zero is unnecessary if you know the string length -- in the case of the example, 11.

It may be unnecessary, but it is convention in C (it may even be in the standard) that strings are zero terminated. To think of strings in C as being null terminated (as they should be) is more compatible to and aids the reader's understanding than attempting to be overly pedantic at this point. Dysprosia 30 June 2005 06:55 (UTC)

[edit] Casting malloc

Although I agree that the discussion is irrelevent to this article, just as a point of interest it is true that most sources now discourage from casting the result of malloc, and from casting void * in general. Doing so is a hang over from Ye Olden Days which is now unnecessary, doesn't serve any good purpose, and can conceal compiler warnings. NicM 20:14, 19 March 2006 (UTC).

I agree that casting from void * is unnecessary, but I'm not sure there's a consensus on whether it is good style, and I definitely don't think that it is "strongly discouraged". It can actually produce some useful compiler warnings; for example:
T *foo = malloc(sizeof T);

If we change the type of foo but don't update the call to malloc, the code will be buggy. One way to fix this is to use malloc(sizeof *foo), although I know a lot of people who find that construct unintuitive. Another way is to use an explicit cast:

T *foo = (T *) malloc(sizeof T);

which ensures that the programmer needs to update the RHS of the assignment if the type of the LHS changes. Now, I can't say I personally find this all that convincing (I would use sizeof *var myself), but that's the argument I've heard for casting away from void pointers in the Postgres source, for example. Neilc

I think that sounds like a fairly horrible reason to use casts. And it still hides the case where stdlib.h is omitted. As you mention, the most reliable way to solve the malloc part of the type-changes-but-programmer-didn't-check-initialisation problem is to use (sizeof *p). NicM 08:43, 20 March 2006 (UTC).
In any case, a few trivial Google searches show that the vast majority of people do discourage casting malloc. Some people do cast it for various reasons, but they do seem to be a minority. Not terribly scientific, but there you go. NicM 08:53, 20 March 2006 (UTC).
Casting malloc is required in C++ (where void* doesn't have an implicit conversion to every other pointer type) (see [[1]]). So code that should compile as either C or C++ must cast the return value of malloc. I am sure I read somewhere that GCC follows this (that its code should be able to compile as C++ as well as the usual C), and the few examples of its code I've seen do cast malloc, but I did not find an actual reference after extensive searching... —Isaac Dupree(talk) 15:03, 24 June 2006 (UTC)
The example states that the program is C, not C++, so casting isn't required. wrp103 (Bill Pringle) 20:00, 24 June 2006 (UTC)
It is a reason used in some real-life C code (though by no means most of it, apparently) to choose to cast malloc, so it seems that it should at least be mentioned as a reason for casting malloc -- that is all. —Isaac Dupree(talk) 20:06, 24 June 2006 (UTC)

[edit] correct spelling?

I admit my experience with anything other than Windows is relatively slim so far, but I thought the term was mAlloc. Wrong?

Liastnir 03:37, 10 April 2006 (UTC)

C is case sensitive. It's malloc. Dysprosia 03:39, 10 April 2006 (UTC)

[edit] Dynamically sized stack allocation is possible

'alloca', commonly available even if not standardised by the C standard, has allowed it for a long time, and C99 specifies that automatic(on-stack) arrays may have their lengths specified by an expression computed at runtime (although actual support for this is relatively low; GCC's support for this is "broken"). So only the lifetime management issue (or a need/desire for extreme portability) is(are) what makes malloc(heap-allocation, that is) necessary in C. Also, recursive function calls can even be used to effectively create a stack-based variable-size linked list, portably. Dynamic amounts of stack memory completely make sense. Of course, historical reasons play a part in what is used the most today, and quite possibly in the original historical reasons for malloc (I don't myself know). I'm not sure how I'd rework the rationale section though, but anyone may feel free to do it (of course!) if they have any idea how to go about it (or are simply feeling more motivated at the moment...). —Isaac Dupree(talk) 22:29, 24 June 2006 (UTC)

Although it is commonly available, alloca is non-standard, machine dependent and spottily implemented. It is often buggy and unsafe, most implementations cannot determine when the allocation exceeds the space available on the stack. The man pages on most OS discourage its use. C99 automatic arrays will be nice, but as you say, GCC doesn't support them properly yet. NicM 09:07, 4 December 2006 (UTC).

The GCC support for variable length arrays is broken? I've been using it. Also, I heard that GCC supported it even before C99. Maybe C99 has an additional requiremente that GCC does not fulfill yet. Does anybody know? Jorge Peixoto

The webpage Variable Length - Using the GNU Compiler Collection (GCC), which I have just found by googling this search terms, supports my idea that GCC supports variable length arrays quite well, but not exactly like C99 demands. Jorge Peixoto 22:52, 20 February 2007 (UTC)

Oh, I have just realized that variable length arrays are supported in GCC by default: one doesn't have to flip a switch like -std=gnu99 or whatever. They wouldn't enable it by default if it was really broken. Jorge Peixoto 23:00, 20 February 2007 (UTC)

They support VLAs, but they are not C99 compliant.[2] Which is a bit useless if you want to target C99. Although apparently it generally accepts C99, it just accepts other stuff too it probably shouldn't. NicM 23:57, 26 February 2007 (UTC).

[edit] Steel Memory Allocator

I'm working on the Steel Memory Allocator, a design I came up with based on everything in the universe just about. The page for it is:

http://steel-malloc.sourceforge.net/

Is this worth adding to 'External links'? I'm basically documenting the entire design of my allocator before I start (site due to be finished 2006 Sep 15) so there's a lot of interesting information; although it's not really much relevant to anything. ;)

At least whoever writes Steel Memory Allocator once it's done will have a lot to go on, since I can't write it myself. —The preceding unsigned comment was added by Bluefoxicy (talk • contribs) 05:38, 14 September 2006.

[personal attack removed] —The preceding unsigned comment was added by 69.216.120.229 (talk • contribs) 19:14, 3 December 2006 (UTC).

[edit] Possible Vanity Link

A new user, User:Davedice contribs, added a link to an article that was apparently created by him. Here is the link:

Could some folks look at this article and decide if this is link is appropriate? Since I'm the person who reverted it, I would prefer not to decide on my own. wrp103 (Bill Pringle) 23:56, 26 February 2007 (UTC)

It looks like a legit paper to me, but it doesn't seem to add a lot to the article since the allocator it covers isn't mentioned. NicM 00:02, 27 February 2007 (UTC).

[edit] Alignment

Not sure if the page is about ANSI C only. But perhaps memory alignment should be mentioned, and functions like memalign(), valloc(), and such? —The preceding unsigned comment was added by Jwagnerhki (talk • contribs) 20:40, 3 March 2007 (UTC).

Retrieved from "http://en.wikipedia.org../../../m/a/l/Talk%7EMalloc_93b7.html"