When IS it necessary to cast the return of malloc( )'s ptr

[RealityVelJackson]

I've seen 'lots' of C code that explicitly casts the ptr returned by malloc, yet I hear that this is not always necessary. Just when is it necessary (if ever) ? Does the situation differ between C and C++ (even though you'd probably use 'new' in C++) ?

MYTYPE* a = (MYTYPE*) malloc(sizeof(MYTYPE));
MYTYPE* a = malloc(sizeof(MYTYPE);

Does malloc() always perform an implicit cast before returning the pointer ?

Thanks,
Jason

 

[Salem]

If it's ANSI-C (or supposed to be), the answer is never.
Doing so potentially hides a serious error, and gains you nothing. The error being a failure to include stdlib.h

malloc returns void*, and in C, void* to type* conversions are automatically handled by the compiler, so there's no need to help it by adding a redundant cast. This does NOT happen in C++.

Missing header file, compiled with a C compiler.

$ cat hello.c && gcc hello.c
#include <stdio.h>
/*#include <stdlib.h>*/
int main ( ) {
  char *p = malloc( 10 );
  free( p );
  return 0;
}

hello.c: In function `main':
hello.c:4: warning: initialization makes pointer from integer without a cast

The fix here is to include the header file.


With header file, compiled with a C++ compiler

$ cat hello.c && gcc -xc++ hello.c
#include <stdio.h>
#include <stdlib.h>
int main ( ) {
  char *p = malloc( 10 );
  free( p );
  return 0;
}

hello.c: In function `int main()':
hello.c:4: invalid conversion from `void*' to `char*'

- In short, you should be using the C++ allocators new and delete if you're writing C++ code.
- Or if you think it should be C anyway, figure out how to invoke your C compiler rather than your C++ compiler.

A common mistake is taking the default file type your IDE gives you (usually C++ it seems), and then trying to write 'C' code with it. Most people then blindly apply the cast because they're programming in the wrong language all of a sudden and do the simple thing just to make the compiler shut up.


The only time casting becomes necessary is if you're using some truly ancient compiler which pre-dates ANSI-C, and has 'prototyped' malloc as returning a char* (the original generic pointer type before void* came along).

--

 

[Clairvoyant1332]

What exactly can happen if you don't include stdlib.h, and more importantly why does the compiler even let you get away with it?

On a couple of occasions, I've used ceil() or floor() in a program and got very stange results. Then I realized that I wasn't including math.h. I would think that the program shouldn't have compiled.

 

[chipperMDW]

Let's take those questions in the reverse order.

why does the compiler even let you get away with it?

C has implicit declarations. If you don't declare a function [tt]foo[/tt] and use it in your code, the compiler pretends you declared it as [tt]int foo()[/tt], meaning it returns an [tt]int[/tt] and can take any number of arguments.

That fact is always a bad thing to rely on. Never let your compiler declare functions for you.

Unfortunately, people used to. Changing the way C works in this regard would break lots of old code.

Most compilers do, however, have a way to warn about missing prototypes, or even treat them as errors. You should normally be using these options with your compiler.

What exactly can happen if you don't include stdlib.h?

Usually, nothing.

Some real life machines, though, have pointers bigger than [tt]int[/tt]s. If you get an implicit declaration of [tt]malloc[/tt] that returns an [tt]int[/tt], the pointer address gets truncated, and then the pointer that's supposed to point to your allocated memory will probably instead be pointing into invalid memory. I don't have to tell you what happens next. ;-)