Printable View
I want to allocate 'n' bytes of memory. How can i do that. I have to get this n value from another variable. If i give n=3, it has to allocate 3 bytes of memory. How can i do this. I tried with the following code. But its not allocating exact bytes.
Can anyone help meCode:
int n;
int *m;
printf("enter n value:");
scanf("%d",&n);
m=(int *)malloc(n);
Thanks in advance
The code is correct. It will allocate at least n bytes.
- 3 bytes maybe not enough to store the int
- malloc allocates at least requested number of bytes - they are available to the program, it can allocate some additional space for internal usage
Define what you mean by this. I have written a couple of responses to similar questions from you. malloc is not guaranteed to give you an EXACT number of bytes. It will give you something that can store the number of bytes you requested - or a NULL pointer.Quote:
Originally Posted by sarathius
--
Mats
I want to get the 'n' value from other variable and i want to allocate those number of bytes. if i give n=3, it has to allocate 3 bytes, if n=4, it has to allocate 4 bytes. I think, now you will be clear
What are you doing this for? Suppose a little more memory is allocated by malloc() than requested. What would be the problem?Quote:
Originally Posted by sarathius
And that code will do that. Are you saying it is not working, if so, by what means are you testing it?
--
Mats
This should be the 100% correctQuote:
Can anyone help meCode:
int n;
int *m;
printf("enter n value:");
scanf("%d",&n);
m=(int *)malloc(n);
Thanks in advance
Code:int n;
int *m;
printf("enter n value:");
scanf("%d",&n);
m=(int *)malloc(n*sizeof(int));
Casting malloc in C is bad, so everyone knows.
Why do u think casting malloc is bad? i always use malloc, it works fine for me, i dont know why you are thinking it is bad in c? if even it were bad in c, it would not be part of c.
Malloc itself isn't bad, but casting the pointer it returns is:
http://faq.cprogramming.com/cgi-bin/...&id=1043284351
You can read FAQ that explains why it is preffered not to cast malloc in CQuote:
Originally Posted by pCBoard.Member
>This should be the 100% correct
You'd be wise to avoid that claim around here. There are some pretty smart people hanging around who will prove you wrong. For example: :)
>printf("enter n value:");
While your implementation is nice enough to flush stdout after this call, not all implementations will do so. In those cases, the only way this prompt will be visible before scanf starts to block for input is if you're lucky enough that the output buffer gets filled up at this point and flushes automatically. Rather than rely on luck or implementation specifics, your code would be more correct to force a flush on stdout:
>scanf("%d",&n);Code:printf ( "Enter n value: " );
fflush ( stdout );
You can't claim your code to be correct because if scanf fails, you've invoked undefined behavior by accessing the indeterminate value of n. Of course, some people don't really care about undefined behavior, so imagine calling malloc with a completely unpredictable size. Even worse, some compilers will kindly initialize local variables to 0, and that's a can of worms with malloc that you don't want to deal with. Your code would be more correct if it took into account scanf failure:
>m=(int *)malloc(n*sizeof(int));Code:if ( scanf ( "%d", &n ) == 1 ) {
/* Use n to allocate memory */
}
else {
/* Handle an input error */
}
This isn't technically an error because you've posted a snippet, but I'll mention that the return value of malloc should always be checked for NULL. Also, it's more correct in C not to cast malloc because the cast can hide a legitimate error of forgetting to include stdlib.h. Since you're removing the cast, you can also remove all mention of m's type (which helps a lot if you decide to change the type):
Code:m = malloc ( n * sizeof *m );
if ( m == NULL ) {
/* Handle an allocation error */
}
I would like to add that if you are manipulating "bytes" instead of, example, integers, you should use a void* instead of a int*, that would be semantically a bit better.
Of course, if you want to allocate memory for n integers, then of course, you should use an int*, but as far as i understand, it's not what you want (you only talk about bytes in your post).Code:int n;
void *m;
printf("enter n value:");
scanf("%d",&n);
m = malloc(n);
>if you are manipulating "bytes" instead of, example, integers,
>you should use a void* instead of a int*, that would be semantically a bit better.
unsigned char would be more intuitive and easier to work with though. Using int is a problem as you're allocating n bytes rather than n integers. That'll cause a lot of confusion when indexing the resulting memory unless you change the size to (n * sizeof(int)). Good catch, I completely missed that. Yet another reason not to claim 100% correctness. Programming is too hard to be 100% correct. ;)
As with the other 4 threads on malloc started by the same person, we probably need to understand what he/she is doing to help further. Unfortunately, it seems like this person prefers to start another thread on a similar subject rather than continue a previous one [this perhaps a misconstrued "Don't wake old threads" - I'm sure 2-3 days WHEN IT'S RELATED is fine - or just inability to find the old thread (considering that there are often 100 threads per day, I'm not surprised)].
--
Mats
>I'm sure 2-3 days WHEN IT'S RELATED is fine
I figure that if it's not on the first two pages, then related or not, the thread is too far gone to reply to. But that's just me. ;)
I guess that is a judgment call [first two pages of a specific board, e.g. C programming, or first two pages of "New posts"?]Quote:
Originally Posted by Prelude
But if it's a very closely related subject, then it just gets fragmented and confusing if the thread is split into four different sections. We are not all on this board all the time, and the original thread may contain information not known to the current reader - it is naturally a balance - on another board where I'm a moderator, occasionally someone will wake threads that are more than 3 years old. Nearly every time, it's for something rather unrelated to the ORIGINAL thread, and thus should not be part of the old thread - time to use the "split thread" button.
--
Mats