is typecasting return from malloc required?

[ceo]

hi,

why do i get the following error? do i need to explicitly typecast the
pointer returned by malloc to char *?

thanks,
ceo

[root@lin1 tmp]# cat malloc.cpp
#include <stdio.h>
#include <malloc.h>
#include <string.h>

int main() {

char *s = NULL;
s = malloc(sizeof( char) * 10);
strcpy(s, "blah blah");
printf("\n%s\n", s);
return 0;
}

[root@lin1 tmp]# gcc malloc.cpp
malloc.cpp: In function `int main ()':
malloc.cpp:8: cannot convert `void *' to `char *' in assignment
[root@lin1 tmp]# gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.2 2.96-108.1)
[root@lin1 tmp]#

[akarl]

ceo wrote:

hi,

why do i get the following error? do i need to explicitly typecast the
pointer returned by malloc to char *?

thanks,
ceo

[root@lin1 tmp]# cat malloc.cpp
#include <stdio.h>
#include <malloc.h>
#include <string.h>

int main() {

char *s = NULL;
s = malloc(sizeof( char) * 10);
strcpy(s, "blah blah");
printf("\n%s\n", s);
return 0;
}

[root@lin1 tmp]# gcc malloc.cpp
malloc.cpp: In function `int main ()':
malloc.cpp:8: cannot convert `void *' to `char *' in assignment
[root@lin1 tmp]# gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.2 2.96-108.1)
[root@lin1 tmp]#

Hint: In which header file is malloc declared?

[ceo]

> Hint: In which header file is malloc declared?

hello akarl,

i get the same error if i include stdlib.h if that's what you meant.

thanks,
ceo

[root@lin1 tmp]# cat malloc.cpp
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main() {

char *s = NULL;
s = malloc(sizeof( char) * 10);
strcpy(s, "blah blah");
printf("\n%s\n", s);
return 0;
}

[root@lin1 tmp]# gcc malloc.cpp
malloc.cpp: In function `int main ()':
malloc.cpp:8: cannot convert `void *' to `char *' in assignment
[root@lin1 tmp]# gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.2 2.96-108.1)
[root@lin1 tmp]#

[Norihiro Kamae]

Because it was compiled as an C++ code.

If you change the file name "malloc.cpp" to "malloc.c",
add typecast operator, or
use new[] operator, you can avoid that error.

But if you compile C++ code (if you try 2nd or 3rd one) with "gcc" or
"cc" command
you will get a link error. To avoid this error you should compile with
"g++" or "c++"

thanks,
Norihiro Kamae in Japan

ceo wrote:

hi,

why do i get the following error? do i need to explicitly typecast the
pointer returned by malloc to char *?

thanks,
ceo

[root@lin1 tmp]# cat malloc.cpp
#include <stdio.h>
#include <malloc.h>
#include <string.h>

int main() {

char *s = NULL;
s = malloc(sizeof( char) * 10);
strcpy(s, "blah blah");
printf("\n%s\n", s);
return 0;
}

[root@lin1 tmp]# gcc malloc.cpp
malloc.cpp: In function `int main ()':
malloc.cpp:8: cannot convert `void *' to `char *' in assignment
[root@lin1 tmp]# gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.2 2.96-108.1)
[root@lin1 tmp]#

[Raymond Martineau]

On 9 Aug 2005 07:43:46 -0700, "ceo" <ce******@gmail.com> wrote:

hi,

why do i get the following error? do i need to explicitly typecast the
pointer returned by malloc to char *?

thanks,
ceo

[root@lin1 tmp]# cat malloc.cpp
That's the problem right here: you're programming in C++, not C. As you
just discovered, C++ has strict typechecking, making it incompatable with
some C constructs.
#include <stdio.h>
#include <malloc.h>
#include <string.h>

int main() {

char *s = NULL;
s = malloc(sizeof( char) * 10);
In C, the statement is perfectly valid.
strcpy(s, "blah blah");
printf("\n%s\n", s);
return 0;
}

[root@lin1 tmp]# gcc malloc.cpp
malloc.cpp: In function `int main ()':
malloc.cpp:8: cannot convert `void *' to `char *' in assignment
[root@lin1 tmp]# gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.2 2.96-108.1)
[root@lin1 tmp]#

[Jirka Klaue]

ceo:

[root@lin1 tmp]# cat malloc.cpp

Engage your brain and rename it to malloc.c.

Jirka

[ceo]

please pardon my stupidity

ceo

[Jirka Klaue]

ceo:

please pardon my stupidity

1. no problem
2. it was a quote (google for "Dan Pop")
3. you deserved it (you are root without knowing what you are doing)
4. I answered question. Well, what else do you want? :-)

Jirka

[E. Robert Tisdale]

ceo wrote:

Why do I get the following error?
Do I need to explicitly typecast the
pointer returned by malloc to char*?
Yes, if you compile with both C an C++ compilers.
cat malloc.cpp #include <stdio.h>
#include <malloc.h>
#include <string.h>

int main(int argc, char* argv[]) {

char* s = (char*)malloc(10*sizeof(char));
strcpy(s, "blah blah");
fprintf(stdout, "\n%s\n", s);
return 0;
}
gcc -x c -Wall -std=c99 -pedantic -o malloc malloc.cpp
./malloc
blah blah g++ -Wall -ansi -pedantic -o malloc malloc.cpp
./malloc

blah blah

[Martin Ambuhl]

ceo wrote:

hi,

why do i get the following error?
Because you are using 'cpp' as the extension, telling the compiler that
it should compile C++ code, not C code.
do i need to explicitly typecast the
pointer returned by malloc to char *?
Not if you invoke your compiler as a C compiler.
[...] [root@lin1 tmp]# gcc malloc.cpp

^^^

[Keith Thompson]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:

ceo wrote:

Why do I get the following error?
Do I need to explicitly typecast the
pointer returned by malloc to char*?

Yes, if you compile with both C an C++ compilers.

[snip]

And there is rarely any good reason to do that.

No, you do not need to cast the result of malloc in a C program; doing
so can mask the error of forgetting to "#include <stdlib.h>". Some
compilers will diagnose this error anyway, but it's unwise to depend
on this.

If you're compiling with a C++ compiler, you're programming in C++,
and this is the wrong newsgroup.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Default User]

E. Robert Tisdale wrote:

ceo wrote:

Why do I get the following error?
Do I need to explicitly typecast the
pointer returned by malloc to char*?

Yes, if you compile with both C an C++ compilers.

The usual stupid "advice" from Trollsdale.


Brian

[E. Robert Tisdale]

Keith Thompson wrote:

E. Robert Tisdale writes:

ceo wrote:

Why do I get the following error?
Do I need to explicitly typecast the
pointer returned by malloc to char*?

Yes, if you compile with both C an C++ compilers.

And there is rarely any good reason to do that.

You code is generally more valuable
if it will compile a either C or C++.
We do this regularly.

C++ is gradually replacing C.
If you follow Keith's advice,
your code will eventually become obsolete.
You will be obliged to re-write it or discard it.
discuss those options with your employer/customer
and decide accordingly.

[CBFalconer]

"E. Robert Tisdale" wrote:

Keith Thompson wrote:

E. Robert Tisdale writes:

ceo wrote:

Why do I get the following error? Do I need to explicitly
typecast the pointer returned by malloc to char*?

Yes, if you compile with both C an C++ compilers.

And there is rarely any good reason to do that.

You code is generally more valuable if it will compile a either
C or C++. We do this regularly.

C++ is gradually replacing C. If you follow Keith's advice, your
code will eventually become obsolete. You will be obliged to
re-write it or discard it. discuss those options with your
employer/customer and decide accordingly.

ERT is known as Trollsdale around here, and his advice is very
rarely worthwhile. If you make your code C and C++ compatible, you
give up the advantages of both. C++ has provisions for linking to
C code, so there is no advantage to taking Trollsdales bad advice.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[John Bode]

E. Robert Tisdale wrote:

Keith Thompson wrote:

E. Robert Tisdale writes:

ceo wrote:

Why do I get the following error?
Do I need to explicitly typecast the
pointer returned by malloc to char*?

Yes, if you compile with both C an C++ compilers.
And there is rarely any good reason to do that.

You code is generally more valuable
if it will compile a either C or C++.
We do this regularly.

You mean you regularly write code that's a ridiculously small subset of
C and C++? You don't use classes, or templates, or any stdio routines?
What, exactly, is the value of such a truncated language?

Of course, that's not what you really meant. You meant that code was
more valuable if it compiled as C++, period.
C++ is gradually replacing C.
Then why bother writing code that will compile as C++ *and* C? Why not
just write C++ and be done with it? Why go through the heartburn of
shoehorning C code into an incompatible compiler?

A pox on Bjarne for calling it C++ and not P like he was supposed to;
and another pox on him for not making a cleaner break with C. At least
then there wouldn't be so much temptation to conflate the two
languages.
If you follow Keith's advice,
your code will eventually become obsolete.
You will be obliged to re-write it or discard it.
Paradigms come and go, but legacy code is forever. I've seen code
written while Nixon was President that's still in service.
discuss those options with your employer/customer
and decide accordingly.

[Keith Thompson]

"John Bode" <jo*******@my-deja.com> writes:

E. Robert Tisdale wrote:

[...]

You code is generally more valuable
if it will compile a either C or C++.
We do this regularly.

You mean you regularly write code that's a ridiculously small subset of
C and C++? You don't use classes, or templates, or any stdio routines?
What, exactly, is the value of such a truncated language?

To be fair, C's <stdio.h> interface is included in C++ (I think the
header name is something like <cstdio>). The intersection of C90 and
C++ is actually pretty close to full C.

This doesn't imply that restricting yourself to that intersection is
worthwhile.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Christopher Benson-Manica]

John Bode <jo*******@my-deja.com> wrote:

Paradigms come and go, but legacy code is forever. I've seen code
written while Nixon was President that's still in service.

It must have been really great code :-)

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Keith Thompson]

Christopher Benson-Manica <at***@nospam.cyberspace.org> writes:

John Bode <jo*******@my-deja.com> wrote:

Paradigms come and go, but legacy code is forever. I've seen code
written while Nixon was President that's still in service.

It must have been really great code :-)

Or perhaps it was just unmaintainable.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[John Bode]

Christopher Benson-Manica wrote:

John Bode <jo*******@my-deja.com> wrote:

Paradigms come and go, but legacy code is forever. I've seen code
written while Nixon was President that's still in service.
It must have been really great code :-)

As Fortran IV goes, it really was well-written, although that
120-branch computed GOTO was kind of a shock.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[REH]

Keith Thompson wrote:

"John Bode" <jo*******@my-deja.com> writes:
To be fair, C's <stdio.h> interface is included in C++ (I think the
header name is something like <cstdio>). The intersection of C90 and
C++ is actually pretty close to full C.

Both are included. The difference is <cstdio> puts everything in the
std namespace, while <stdio.h> does not. I believe that the later is
depricated.