Regarding releasing memory allocation in C_问答_开发者

I have a multiple choice question about memory allocation C, but I'm sure which one is the right answer.

Which of the following statments about releasing memory allocation is false?

a. It is an error to dereference a pointer to allocated memory after the memory has been released.

b. It is an error to free memory with a pointer to other than the first element of an allocated array.

c. Memory should be freed as soon as it is no longer nee开发者_运维技巧ded.

d. Only one call to free is necessary to release an entire array allocated with calloc.

e. To ensure that it is released, allocated memory should be freed before the program ends.

They all look right to me :( ! Any idea?

Thanks

As given by the other answers, e is the answer. The interesting option however is c which is highly subjective. There's not necessarily any reason to free memory as soon as possible, and it's favorable to delay this in certain circumstances.

For example, if you know that a certain memory block will be surely re-allocated soon after it's freed, it may cost less to simply retain it in a pointer, rather than freeing it. It would hopefully be clear in each case whether having such a retained pointer makes sense and fits within the architecture of the code (code smell!). Sometimes a minor performance loss wins over having less readable code -- use your judgment and measure if unsure!

The answer is e. When a process ends, the operating system will release all the resources it currently holds, including allocated memory.

Therefore there is no need to free memory before ending a program.

I think the option (e) is wrong. Because when the program ends, all allocated memory is freed by the OS whether you do it manually or not. OS itself ensures that. No need to ensure it by freeing manually!

a. True: It is just a case of dangling pointer.

b. True: The pointer passed to free() must point to the head address of the array.

c. Subjective and not always true, but not always false either.

d. True: Multiple freeing leads to undefined behavior. Your program may crash, or it may launch a nuclear attack.

e. False: Memory allocated by malloc() and functions from its family, remains committed until they are de-allocated by means of free(). In general, using only standard library functions, a running C program has no way of knowing when allocated blocks of memory have been orphaned. However, an operating system will reclaim all such memory when the process terminates.

I think (e) is a right answer here, and everybody else is correct about it, as far as they go, but I think (c) is also a right answer.

First, on some systems (embedded systems, perhaps), there might not be a guarantee that the OS will deallocate all memory. Admittedly not a common case these days, but then, so is C programming at all, it seems!

But more importantly, if you admit that the OS is going to deallocate all of your memory en masse anyway (e), why 'should' memory be freed as soon as it is no longer needed? Unless you would have needed the memory earlier, isn't that just extra code, which takes time to run and can have bugs itself? (If I had a dollar for every deallocation bug I've found...) What if it's just 2 bytes, and it'd take more code to free it than memory you're freeing?

After having written many programs (and many more bugs), I think that memory should be released when it's convenient and can be done robustly, unless there's a good reason (and "I have a ton of memory allocated" can be a very good reason!). That's the point of making the OS free your pages when the program exits, after all. That's also the point of GCs: object lifetimes are hard.

"As soon as it is no longer needed" is for 1970's computers and standardized textbooks.