Thread: memory allocation in bytes

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

Originally Posted by sarathius

But its not allocating exact bytes.

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.

--
Mats

Originally Posted by sarathius

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?

And that code will do that. Are you saying it is not working, if so, by what means are you testing it?

--
Mats

Casting malloc in C is bad, so everyone knows.

Malloc itself isn't bad, but casting the pointer it returns is:
http://faq.cprogramming.com/cgi-bin/...&id=1043284351

Originally Posted by pCBoard.Member

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.

You can read FAQ that explains why it is preffered not to cast malloc in C

>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:

Code:

printf ( "Enter n value: " );
fflush ( stdout );

>scanf("%d",&n);
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:

Code:

if ( scanf ( "%d", &n ) == 1 ) {
  /* Use n to allocate memory */
}
else {
  /* Handle an input error */
}

>m=(int *)malloc(n*sizeof(int));
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.

Code:

int n;
void *m;

printf("enter n value:");
scanf("%d",&n);

m = malloc(n);

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).

>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.