Printable View
I really don't get the point of malloc. Say I have the following code:
This will print "123456789". Since I've only allocated one byte, why doesn't it just print "1"? Also, if I get rid of ptr = malloc(1), the code still works exactly the same. So what the heck??Code:int* ptr;
ptr = malloc(1);
*ptr = 123456789;
printf("%d\n", *ptr);
free(ptr);
That is very bad code. Malloc allocates memory for you to use.
ptr might just point to some random memory that might work, but it's really, really bad design. It can just as well crash. But don't expect malloc to just allocate one byte. When allocating memory, you get lat least the number of bytes you request, but sometimes more.
But always allocate the minimum amount of memory you need to work with - in that case, 4. Otherwise you can get unexpected results.
In this case, an accident probably saved you from yourself. ;)
malloc() is most likely unable or unwilling to allocate only 1 byte of memory for you, hence you are probably actually having more than that being allocated. Nevertheless, this behavior, is potentially undefined, which means if you try this on another machine, you may as well crash since an int on most modern systems is a 32-bit number, which is 4 bytes.
Dynamically allocating memory is useful in cases where you will not know how much memory to allocate until runtime. Consider a program that has to read in an entire file and do some processing.... and assume that for whatever reason you need to have the entire file in memory, not just parts of it (although this is not always likely). How can you accomplish this? You could declare a massive array, but if you guess too small, your program can't read certain files. If you guess too large, your program wastes a substantial amount of memory. That plus arrays are limited in how big they can be on the stack.
Hence your alternative is to attempt to allocate about as much memory as you need when you need it. That's what malloc() and free() is for.
malloc() allocates data from the heap. On a Mac in OS X, the smallest amount of memory that you can get is 16 bytes, even if you ask for 1 byte. You operating system may be different. Your example just "happens" to work since your process "happens" to own the memory it is writing to.
Todd
Technically, the code you've just posted is not correct. You can't [on any ordinarily available machine] use 1 byte (the unit for malloc) and store an int - it takes 2 or 4 bytes. So correctly, you should doto ask for the right amount of memory for one integer.Code:ptr = malloc(1 * sizeof(int));
It is of course a very silly example - there is no need to allocate memory at all for one integer in this example - you could just remove the star in front of ptr [and preferrably rename ptr], remove the malloc line altogether and remove the stars on assignment and printing, remove the free-line, and you'd get exactly the same result.
But then it would not be an example of allocating memory, which I suspect it is supposed to be. If this is part of some "real" code, then it's defnitely a bad choice. This is more like the woodworking stuff you do when you start doing woodwork at school - you cut a few pieces of wood and put them together, and call it a bookend or some such - but it's really not an advanced thing, just something to teach you the basic techniques of woodworking. Same if you learn to weld or solder - you start by just attaching bits of scrap metal together, then you do more advanced stuff. Get the idea?
--
Mats
Here's an example to see for yourself on your system how much memory will be allocated.
ToddCode:#include <stdio.h>
int main()
{
int j ;
char *data ;
for (j = 0 ; j < 10 ; j++ ) {
data = malloc(1) ;
printf("Address of memory is %04p\n", data) ;
}
}
Wow, thanks for the quick replies!
Ok, so I played around with my code a bit more and I have this now:
And thank goodness it crashed. Because if that code didn't cause any errors, I would be so confused.Code:char* ptr;
ptr = malloc(1);
if (ptr == NULL)
printf("err");
else
{
*ptr = "abcdefghijklmnopqrstuvwxyz-1234567890";
printf("%s\n", *ptr);
free(ptr);
}
So now that I'm using a c-string, how to malloc space on the fly? What do I put in the parameter for malloc?
EDIT:
I just want to thank you guys for the clarifications on malloc(), and that some systems allocate a min of say 4 or more bytes.
That code is still just so wrong.
You aren't assigning a string - you're assigning an adress and no, it's not just one byte long.
I know it's just one byte long. That's the point. THis is just testing code, and I was wondering how I would allocate the appropriate amount of space for a c-string of x on the fly.. I'm guessing it would be malloc(x *sizeof(char))?
And what do you mean by "You aren't assigning a string - you're assigning an adress "? I'm dereferencing the pointer to insert data, and then I dereference it again to retrieve that data and print it. What's wrong with that? What's the proper way?
"something" == char*
So, *ptr = "Something" means *ptr = some_address_here;
The real way would be strcpy for C.
You're wrong about memory allocation too. One character takes one byte, so you need to do
All C strings have one extra byte at the end with the value 0 that tells all functions that this is the end of the string.Code:malloc(sizeof(char) * length_of_string + 1);
If you actually look at the assembly code, you'll see that the compiler takes the lower byte of the address of the string and puts it into ptr. In my testing, it put 0x38 there (which represents the character '8').
Unfortunately, this kind of thing is valid code in C, but fortunately, not in C++.
A pointer contains the address where a value is. Malloc(1) means you're allocating only one byte for a char array (!!!), which is only good for a NULL array (aka ""), because char array's length should be at least the text's length + 1 (null terminator).
With integer values (char, short, int etc) you can use this technique to get data into the pointed address:But in case of a string (char array), it doesn't do what you want it to do. It makes the pointer point to a new location (the string you specified, hardcoded somewhere in the program memory) and means that the memory address of allocated memory gets lost, which means a memory leak.Code:*acharptr='A'; //note that 'A' represents an integer
*acharptr=245; //unsigned char can hold a value up to 255
*anintegerptr=50000;
To get data into a buffer, you should do something like this:
If you allocate memory for a char array, you MUST allocate enough bytes for the data you want to put into it. And if you don't know how long string it has to carry, then you could use a power of 2 as the length (256,512,1024 etc).Code:strcpy(ptr, "abcdefghijklmnopqrstuvwxyz-1234567890");
And if you know the length of what you want to copy there:Code:char *ptr;
ptr=malloc(1024*sizeof(char));
strcpy(ptr,"blablablabla");
strcat(ptr,"morestuff"); //append to char array
sprintf("string---> %s",ptr); //note that %s means a char array (char*), so no *ptr here
free(ptr);
Code:char* ptr;
ptr=malloc((sizeof("yourstringhere")+1)*sizeof(char));
strcpy(ptr,"yourstringhere");
sprintf("string---> %s",ptr);
free(ptr);
K, so I'm trying to put a char array into a pointer. Maybe this doesn't make much sene, but yea. The following is bad code, I know that it is, but help me out.
Code:char* ptr;
char word[26] = {'a','b','c','d','e','f','g','h','i','j','k','l','m','n','o','p','q','r','s','t','u','v','w','x','y','z'};
int count = 0;
ptr = malloc(sizeof(char) * strlen(word) +1);
if (ptr == NULL)
printf("err");
else
{
//How do I copy over the char array into the pointer? This is wrong...
for (count=0; count<strlen(word); count++)
strcat(ptr, word[count]);
printf("%s\n", ptr); //this is wrong
free(ptr);
}
Also beware, because strlen returns the length of strings, not including the NULL char. So when allocating memory from the length of a given string gotten from strlen, add +1 to it.Code:char mystr[50];
char* pMyStr = malloc(sizeof(char) * 50);
strcpy(mystr, "abcdefghijklmnopqrstuvwxz");
strcpy(pMyStr, "abcdefghijklmnopqrstuvwxz");
free(pMyStr);
It's all very simple.
What does this print and why?Code:#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main( void )
{
const char * str_static = "You can give a string literal a name."; /** assigning the address of a string literal **/
char * str_heap = malloc( strlen( "You can store a string on the heap." ) + 1 );
if( str_heap != NULL ) {
char str_auto[] = "You can store a string on the stack.";
strcpy( str_heap, "You can store a string on the heap." );
puts( str_auto );
puts( str_static );
puts( str_heap );
free( str_heap );
}
return 0;
}
When you can answer that you will understand.
strlen won't work here, since you don't actually have a NUL at the end of your array of alphabet letters - the array only holds 26 elements, and none of those is zero. In this particular case you could use sizeof(word) - but that only works if you have a local array.Quote:
Originally Posted by I-See-C
THis is also broken:
word[count] is a single char, and you are copying a string ptr into it - it will crash, I can guarantee it [assuming you ignore the warnings that the compiler will give for trying to pass a char as a pointer].Code:strcpy(word[count], ptr);
--
Mats
Elysia demonstrated a char array as a local variable. Only use it as a local variable for small amounts of memory (maybe up to 1 Kbyte).
I-See-C, the code you posted is way too overcomplicated (and yeah, it's bad code lol).
And this is it!Code:char word[]={"abcdefghijklmnopqrstuvwxyz"}; //the compiler calculates the length itself here
//(and adds a NULL terminator), don't worry about it
ptr=malloc(sizeof(word) * sizeof(char));
if(ptr==NULL){
printf("err");
}
else{
strcpy(ptr,word); //strcpy copies a whole string, not only one char
printf("%s\n",ptr); //%s = char* (so yes, no *)
free(ptr);
}
Edit: Oops, sizeof and strlen mixed, sorry. :D
Wow, there is a wealth of information here. I tried searching all over the web for information on malloc, and nothing even came close to the great information provided here, not only on malloc, but other lil' parts of C. Thank you everyone, especially maxorator, Elysia, and matsp.
Hmm.. Using maxorator's code, I changed the 2nd line to:I thought this would crash or cause errors, but everything still works perfectly fine. I tried substantially increasing the length of the char array, and it still didn't cause any errors. Why isn't crashing?Code:ptr = malloc(1);
1) Malloc may allocate enough memory
2) You "luckily" enough write into process owned memory (but maybe at the cost of overwriting something).
Don't assume it will crash - sometimes it won't, sometimes it will. Just avoid doing such bad practices because they'll but you in the ass and you'll tear you hair out when you can't find out why later.
lol, k.
And just one finally question:
If I do:
I get the exact same result without having to use malloc, and the code is much simpler. So why do we use malloc?Code:char* alpha;
alpha = "abcdefghijklmnopqrstuvwxyz";
printf("%s", alpha);
Using an uninitialized pointer is kind of like pointing a handgun in the dark and pulling the trigger. You might hit your target. On the other hand, you might hit your grandma.Quote:
Originally Posted by I-See-C
We use malloc to get more memory! For onesies or twosies, there's not usually a point. For a 50 byte constant string, there's no point there either. Think on a bigger and more dynamic scale.Quote:
Originally Posted by I-See-C
Let's say you have to read a 20MB file into memory and parse through it a few times. Do you really want to reserve 20MB in your program to do this? If you did, your .exe file is 20MB large, plus the size of your code, with might be 1K. (1,000 bytes, roughly).
Look at it this way. If your buddies wanted to download your program, it would be a 20.001MB download. However, if you used malloc() on your program, it would be a 1K download.
Todd
Yes, this is fine because the compiler will put that string, usually in the data segment and assign the address of that string to your pointer. So that's fine.Quote:
Originally Posted by I-See-C
However, the compiler usually puts it in a read-only segment, so what happens when you need to modify that string? Access violation! Crash! So, you need to allocate it on the stack or the heap.
LOL.Quote:
Originally Posted by brewbuck
Nice analogy!
Another catch: if you don't use malloc, you're limited to the size of the stack, which usually is around 1 MB (default on Windows). So if you use more than one MB of memory... uhoh! You need to allocate on the heap (in the computer RAM), which is exactly what malloc does!Quote:
Originally Posted by Todd Burch
And another reason is, as mentioned, dynamically allocating memory - allocating when you need some memory for something, whatever that may be.
Read my post and don't post again until you've read it.Quote:
Originally Posted by I-See-C
[pedant]Quote:
Originally Posted by Todd Burch
Actually, unless you also initialize the memory, it will take no space at all [as there is already a field saying "how big is the un-initialized data section", and it doesn't matter if that field is 0x38, 0x1438 or 0x1400038 - it's a 32-bit value anyways ]. And the stdio package and such probably come to a few kilobytes when you link it in.
[/pedant]
But I agree with the concept of "think big" or "think unknown". If you know how much you could possibly expect, then a staticly sized array is most often the right solution. When you need LOTS of memory, or you need a highly variable number of "things", then malloc is the right solution. If you need "at most 100", then it's fine to use a fixed size array. If you don't know if you need 15 or 150000, then use dynamic memory in some form. There is of course no hard and fast rules, and the amount of memory you "may want to use as a static array" can vary greatly from system to system - a small embedded system may not be the ideal place to put a 15 * 100 array as a local variable [as that is 1500 bytes, and the stack may be only 2KB in total size, for example] - but on a desktop PC, that's not a big deal at all - the stack can grow to megabytes, and 1500 bytes is nothing in this case.
--
Mats
Thanks for the clarifications. And MacGyver, I previously read your post but it didn't cover all the bases. Just because you think your single explanation seems to be the utmost best at answering everything, doesn't mean it truly is. Remember, I'm not you.
The stack comments only apply to local automatic variables - you can use as much memory as you like in global variables or local static variables. There are of course all sorts of good reasons NOT to use global variables, but if for example what you are doing is to process a large image-file, and you wish to just read 16 MB of image-file into memory, then you can do that into a global variable - no problem from that perspective [you may need to THINK about what you are doing to it in terms of processing, but that applies if you pass a pointer to some 16MB around too - it's essentially no difference, except your pointer may be a local variable in main or "doProcessing" or some such].Quote:
Originally Posted by Elysia
--
Mats
I don't think my explanation was the only one or the best. I just get irritated with people asking the same questions that other people have answered.Quote:
Originally Posted by I-See-C
We have the same questions asked repeatedly. More than once per thread... well, yeah. It gives the appearance you're not even reading anything we're writing.
Because Lets say you wanted to change the first letter alpha points to to an 'A' (uppercase instead of lowercase). That will likely crash as you'd be trying to modify memory that's part of your applications static data segment.Quote:
Originally Posted by I-See-C
If you malloc a copy first, then you can do whatever you want to the copy.
But global variables aren't put on the stack, are they? They're put in a special section if I'm not mistaken.Quote:
Originally Posted by matsp
Exactly my point.Quote:
Originally Posted by Elysia
--
Mats