469,921 Members | 2,198 Online

# Question regarding malloc

121 100+
emmm, this is taken from the exam I just finished this morning:

Which one is correct:

Expand|Select|Wrap|Line Numbers
1. A) double *ptr = (double *) malloc(100 * sizeof(double));
2. B) double *ptr = (double *) malloc(100 * sizeof(double *));
3. C) double ptr = (double) malloc(100 * size0f(double));
4. D) double *ptr = (double) malloc(100*sizeof(double));
My choice is A.

But if you take a look at potion B, it says:
"allocate 100 times of the memory size for a pointer to double and then cast the void pointer to be of type double, finally assign it to a pointer to double called ptr."

I guess B is also correct on syntax, though not as that meaningful as A.

To prove this, here is my code fragment:

Expand|Select|Wrap|Line Numbers
1. #include <stdio.h>
2. #include <stdlib.h>
3.
4. int main()
5. {
6.    double *ptr = (double *) malloc(100*sizeof(double *));
7.
8.    printf("Hello there!\n");
9.    return 0;
10. }
It was compiled successfully and generated the correct output...

BTW I found many funny questions in exam, such as this one:

Which one is NOT a reserved word in c?
A) int
B) for
C) sizeof
D) exit
Nov 20 '07 #1
6 1202
1,435 Expert 1GB
Both A and B seem to be correct.
But A seems to be an answer which your examiners would be looking for.
Nov 20 '07 #2
gsi
51
Hi,

double *ptr = (double *) malloc(100 * sizeof(double *));

may be syntactically correct, but semantically wrong. It may be right , but it is thoroughly implementation defined. Because in this context if this is going to be right on a given implementation , then the size of a double is equal to the size of a pointer in that implementation.

int *ptr = (int*) malloc(100 * sizeof(int*)); --> this may hold good in many 32 bit unix implementation's but again undefined.

Thanks,
Gsi.
Nov 20 '07 #3
mattmao
121 100+
double *ptr = (double *) malloc(100 * sizeof(double *));

may be syntactically correct, but semantically wrong
Sorry, I don't quite follow you.

I already mentioned the meaning of option B, it makes fully sense to me. And if you want to allocate some memory space for the size of 100 pointer to double (s), then you should do it that way.

The original question is taken from a exam paper, so we shouldn't consider too much about the actual code implementation, anything that is legal should be recognized as a correct answer.

Since the cast is not critical to option B, we could replace it with:

void *ptr = malloc(100*sizeof(double *));

void ptr is only used for keeping the memory address of this allocated memory, what's going on is not for our consideration...
Nov 20 '07 #4
oler1s
671 Expert 512MB
None of those possible answers are correct. malloc gets you a pointer to a memory block. So if you allocate memory for ints, you get a pointer to an int array. If you allocate for doubles, you assign to a double pointer. If you allocate for double pointers, you assign to a pointer to a double pointer.

Furthermore, you should always be using the recommended malloc idiom. That is:

p = malloc(n* sizeof *p)

Therefore, you should have double** ptr = malloc(100 * sizeof *ptr);

--

Potentially you could assign to a void pointer. Effectively, it's a dumb idea. (No offense). There's several reasons, and if you can't figure them out, I'll walk through them.
Nov 20 '07 #5
mattmao
121 100+

Yes it compiles but it is also wrong.

sizeof(double *) will give you the size of memory for a pointer to a
double. This is usually 4 bytes on most machines. sizeof(double) will
give you the size of a double, which is usually 8 bytes.

Therefore A will set aside 800 bytes while B will set aside 400 bytes.

Under such conditions it's very easy to get segmentation faults when you
try and access some of the array, as not enough memory has been
allocated for it.
This is taken from my lecturer's reply...And I think that could end this discussion, it seems that he doesn't care too much about the meaning of allocating 100 double pointers...

Thank you for all of the helps. I found learning to program in c is pretty straight forward and interesting. Next semester I would continue to study in C++ :)
Nov 21 '07 #6
oler1s
671 Expert 512MB
Your lecturer's reply doesn't end the discussion. He doesn't actually answer the question. Furthermore, his implications are disturbing, because they smack of just bad programming.

Under such conditions it's very easy to get segmentation faults when you
try and access some of the array, as not enough memory has been
allocated for it.
And this means what? Obviously you'll get a segmentation fault if you allocate too little memory, and then correctly access parts of the array which you assume you have memory access to.

I have to question if that was really a lecturer's reply, because two possibilities arise: he needs to pick up K8R's book and learn C, or he is incapable of giving a technically coherent answer.
Nov 21 '07 #7