why is casting malloc a bad thing?

Brian Blais <bb****@bryant.edu> scribbled the following:

Hello, I saw on a couple of recent posts people saying that casting the return
value of malloc is bad, like: d=(double *) malloc(50*sizeof(double)); why is this bad? I had always thought (perhaps mistakenly) that the
purpose of a void pointer was to cast into a legitimate date type. Is
this wrong? Why, and what is considered to be correct form?

It's not exactly _wrong_ but doesn't help anything either. Why people
discourage it is because of these reasons:
1) There is no need to. malloc(), correctly prototyped, returns a
void *, which is assignable to any object pointer type anyway.
2) If malloc() is not correctly prototyped, casting the return value
won't fix anything. malloc() will still return int, and casting that
int to an object pointer type isn't magically going to change it to a
pointer.
3) If malloc() is not correctly prototyped, the code is broken, because
it causes undefined behaviour. However casting the malloc() will make
the compiler _think_ it's not broken, although it really is.
The correct form is simply:
d = malloc(50*sizeof(double));
or:
d = malloc(50*sizeof *d);

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Hasta la Vista, Abie!"
- Bart Simpson

Brian Blais <bb****@bryant.edu> wrote in news:40************@bryant.edu:

Hello,

I saw on a couple of recent posts people saying that casting the return
value of malloc is bad, like:

d=(double *) malloc(50*sizeof(double));
See the C-FAQ as to why.

http://www.eskimo.com/~scs/C-faq/q7.6.html
http://www.eskimo.com/~scs/C-faq/q7.7.html
why is this bad? I had always thought (perhaps mistakenly) that the
purpose of a void pointer was to cast into a legitimate date type.

Negative. Void pointers can hold any type of pointer so they naturally
"become" the desired type.

E.g.

void foo(void *pThing)
{
int idx;
char *pChar = pThing;

/* work with pChar */
for (idx = 0; idx < 10; ++idx)
{
pChar[idx] = 'a';
}
}

void bar(void)
{
int arr[100];

foo(arr);
}

No icky casts needed or desired. Void is your friend.

--
- Mark ->
--

Brian Blais wrote:

Hello,

I saw on a couple of recent posts people saying that casting the return
value of malloc is bad, like:

d=(double *) malloc(50*sizeof(double));

why is this bad? I had always thought (perhaps mistakenly) that the
purpose of a void pointer was to cast into a legitimate date type. Is
this wrong? Why, and what is considered to be correct form?

A pointer to void (void *) can be *implicitly* converted from and to a
pointer to any object type, making the cast unnecessary. It is likely
that the confusion arises from the fact that this was not the case in
pre-ANSI (referred to as K&R) C, where the explicit cast *was* necessary.

The preferred for of the call to malloc() above is:

d = malloc(50 * sizeof *d);

This has several advantages:

It's shorter. ;-)

If one fails to #include <stdlib.h> (in which case the return type of
malloc() reverts to implicit `int') an error will be generated. This is
particularly significant on platforms where the size of `int' and `void
*' differ; in such cases the explicit cast would allow the code to
compile, but behave strangely..

If the type of `d' changes, the form of the malloc() call does not have
to be changed.

In general, casting is evil, except where it's necessary. Since it isn't
necessary in this case, why do it?
This issue has appeared repeatedly on news:comp.lang.c. If you have
further questions, I would recommend searching the archives (through,
for example, http://groups.google.com).

HTH,
--ag
--
Artie Gold -- Austin, Texas

Brian Blais <bb****@bryant.edu> wrote:

I saw on a couple of recent posts people saying that casting the return
value of malloc is bad, like:

d=(double *) malloc(50*sizeof(double));

why is this bad?
For the same reason that hanging a "danger - high voltage" sign on a
normal battery is wrong.
Casts are used to circumvent the C type system. If you use them where
the type system does not need to be circumvented, you give off the wrong
signals: that something odd is going on on that line (which it isn't),
and that you're unsure about how the type system works (which you
shouldn't be).
I had always thought (perhaps mistakenly) that the
purpose of a void pointer was to cast into a legitimate date type. Is
this wrong?

This is quite the opposite of right. The purpose of a void * is to help
you _not_ need useless casts all over the place.

Richard

"Brian Blais" <bb****@bryant.edu> wrote in message
news:40************@bryant.edu...

Hello,

I saw on a couple of recent posts people saying that casting the return
value of malloc is bad, like:

d=(double *) malloc(50*sizeof(double));

why is this bad? I had always thought (perhaps mistakenly) that the
purpose of a void pointer was to cast into a legitimate date type. Is
this wrong? Why, and what is considered to be correct form?

thanks,

You will find folks on both sides of the issue.
The main (some would say *only*) argument against
casting the result is that it will hide the failure
to include <stdlib.h> which declares malloc to return
(void *). The compiler will assume it returns (int),
and casting (int) to (something *) will cause undefined
behavior.

The folks on the other side of the argument say that
their compiler will complain loudly when a function
is referenced without a declaration (implementation-defined behavior), so the
question about including <stdlib.h>
is moot. Once past the question of proper malloc()
declaration, one must contend with the whether the
target pointer is what one intended.

======================
#include <stdlib.h>

static void fubar(void)
{
float * d; /* programmer changed this...! */

/* some dozen lines later in the code */

/* silent erroneous size calculation */
d = malloc(50*sizeof(double));
}
======================

If the programmer decides to change the declaration
of "d", the compiler will *NOT* catch the bad assignment.

If the assignment used a cast (double *), then the
compiler would complain about incompatible pointer
types.

======================
#include <stdlib.h>

static void fubar(void)
{
float * d; /* programmer changed this...! */

/* some dozen lines later in the code */

/* incompatible pointer assignment */
d = (double *) malloc(50*sizeof(double));
}
======================

Another suggestion is *not* to use "sizeof(double)",
but use "sizeof *d", so that the element size changes
automatically when changing the target declaration.

======================
#include <stdlib.h>

static void fubar(void)
{
struct gonk * d; /* programmer changed this...! */

/* some dozen lines later in the code */

/* 50 elements of whatever "d" points to... */
d = malloc(50*sizeof *d);
}
======================

Now the malloc() is compatible with changing the
target type of the pointer variable "d". You can
change it to any kind of pointer type and the
malloc will be compatible. This is the recommended
way to use malloc(), so that:

1. A missing <stdlib.h> is caught.

2. The malloc() assignment is always compatible
with any pointer type.

3. The size calculation changes along with any
change to the target declaration.
If you insist on using sizeof(double) in the size
calculation, then you should cast the result so that
the compiler will complain when the target type is
changed (so that you can change the sizeof() and
recompile). However, you will save yourself some
maintenance headaches by using: "d = malloc(50*sizeof *d);"

2 cents worth. Your mileage may vary.

--
----------------------------
Jeffrey D. Smith
Farsight Systems Corporation
24 BURLINGTON DRIVE
LONGMONT, CO 80501-6906
http://www.farsight-systems.com
z/Debug debugs your Systems/C programs running on IBM z/OS!
Are ISV upgrade fees too high? Check our custom product development!

Brian Blais wrote:

I saw on a couple of recent posts people saying that casting the return
value of malloc is bad, like:

d=(double *) malloc(50*sizeof(double));

why is this bad? I had always thought (perhaps mistakenly) that the
purpose of a void pointer was to cast into a legitimate date type. Is
this wrong? Why, and what is considered to be correct form?

AFAIK it is wrong as <stdlib.h> should already have declared malloc the right
way. By overriding the standard declaration, you risk to re-declare malloc() in
a way it is not ment to. In other words, the <stdlib.h> declaration is the only
correct one, it must work and if it does not it means either that it's broken
or that <stdlib.h> has not been included.

A nice description of the "problem" can be found in:
http://users.powernet.co.uk/eton/c/hackerhotel.html

Ciao,
--
Roberto Divia` Love at first sight is one of the greatest
============= labour-saving devices the world has ever seen.
Mailbox: C02110 CERN-European Organization for Nuclear Research
E-mail: Ro***********@cern.ch CH-1211 GENEVE 23, Switzerland

xarax <xa***@email.com> scribbled the following:

"Brian Blais" <bb****@bryant.edu> wrote in message
news:40************@bryant.edu...

Hello,

I saw on a couple of recent posts people saying that casting the return
value of malloc is bad, like:

d=(double *) malloc(50*sizeof(double));

why is this bad? I had always thought (perhaps mistakenly) that the
purpose of a void pointer was to cast into a legitimate date type. Is
this wrong? Why, and what is considered to be correct form?

thanks,

You will find folks on both sides of the issue.
The main (some would say *only*) argument against
casting the result is that it will hide the failure
to include <stdlib.h> which declares malloc to return
(void *). The compiler will assume it returns (int),
and casting (int) to (something *) will cause undefined
behavior. The folks on the other side of the argument say that
their compiler will complain loudly when a function
is referenced without a declaration (implementation-defined behavior), so the
question about including <stdlib.h>
is moot. Once past the question of proper malloc()
declaration, one must contend with the whether the
target pointer is what one intended.
I don't understand this argument at all. Without the correct
prototype, using the return value of malloc() causes undefined
behaviour, *CAST OR NO CAST*. The code is broken anyway. *With*
the correct prototype, the cast is completely needless.
======================
#include <stdlib.h> static void fubar(void)
{
float * d; /* programmer changed this...! */ /* some dozen lines later in the code */ /* silent erroneous size calculation */
d = malloc(50*sizeof(double));
}
====================== If the programmer decides to change the declaration
of "d", the compiler will *NOT* catch the bad assignment.
This is why most folks prefer to write:
d = malloc(50*sizeof *d);
and let that solve the problem for them.
If the assignment used a cast (double *), then the
compiler would complain about incompatible pointer
types.
Which would not have ever arisen if they had used the form I
presented above.
======================
#include <stdlib.h> static void fubar(void)
{
float * d; /* programmer changed this...! */ /* some dozen lines later in the code */ /* incompatible pointer assignment */
d = (double *) malloc(50*sizeof(double));
}
====================== Another suggestion is *not* to use "sizeof(double)",
but use "sizeof *d", so that the element size changes
automatically when changing the target declaration.

Yes, like I just described.

(Snip example)

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"'It can be easily shown that' means 'I saw a proof of this once (which I didn't
understand) which I can no longer remember'."
- A maths teacher

"Brian Blais" <bb****@bryant.edu> wrote in message
news:40************@bryant.edu...

Hello,

I saw on a couple of recent posts people saying that casting the return
value of malloc is bad, like:

d=(double *) malloc(50*sizeof(double));

why is this bad? I had always thought (perhaps mistakenly) that the
purpose of a void pointer was to cast into a legitimate date type. Is
this wrong? Why, and what is considered to be correct form?

thanks,

You do not have to cast a pointer to void as it can be converted to or from
a pointer to any incomplete or object type.

The issue with casting from malloc is not that it is just superfluous
but that you might be suppressing a warning that might otherwise
be useful.

Brian Blais

Casting of void* is required in C++, so i usually do it in C also. It's not
required, but it makes it easier when switching between C and C++, like I
often do.

"Mark Bruno" <ya*************@yahoo.com> wrote in
news:_-********************@comcast.com:

Casting of void* is required in C++, so i usually do it in C also. It's
not required, but it makes it easier when switching between C and C++,
like I often do.

So are you saying if I didn't name all my loop variables 'new', 'delete',
'cout', 'cin', etc. I'd have an easier time porting? BTW, why would you
ever use malloc() in C++?

--
- Mark ->
--

Mark Bruno wrote:

Casting of void* is required in C++, so i usually do it in C also. It's not
required, but it makes it easier when switching between C and C++, like I
often do.

You shouldn't be using malloc() in C++ period. Writing code to move back
and forth like that is poor idea. C++ is its own language, and you
should be writing C++ code using the modern libraries. Don't write
cripple C code for C++ applications.

I work in both languages, it's not that hard.

Brian Rodenborn

Brian Blais wrote:

I saw on a couple of recent posts
people saying that casting the return value of malloc is bad, like:

double* p = (double*)malloc(50*sizeof(double));

Why is this bad?
It isn't.
I had always thought (perhaps mistakenly) that
the purpose of a void pointer was to cast into a legitimate date type.
Is this wrong?
No.
Why and what is considered to be correct form?

This is just a style issue.

I always use the explicit cast
to prevent my C++ compiler from complaining about

warning: invalid conversion from `void*' to `double*'

It applies the implicit conversion anyway so it doesn't matter
except that more important warnings some times get lost
if too many warning messages such as this are issued by my compiler.

The important thing here is to adopt a style and stick to it.

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in
news:40**************@jpl.nasa.gov:

Do you really work for NASA yet spew such rubbish?

I saw on a couple of recent posts
people saying that casting the return value of malloc is bad, like:

double* p = (double*)malloc(50*sizeof(double));

Why is this bad?
It isn't.

It is not proper C. To the OP, ignore E. Robert Tisdale's response and
read the C-FAQ instead.

I had always thought (perhaps mistakenly) that
the purpose of a void pointer was to cast into a legitimate date type.
Is this wrong?

No.

It is.

Why and what is considered to be correct form?

This is just a style issue.

It is not.
I always use the explicit cast
to prevent my C++ compiler from complaining about
You *shouldn't* use malloc in C++!
The important thing here is to adopt a style and stick to it.

True but this is not a style issue.

--
- Mark ->
--

Mark A. Odell wrote:

It is not proper C.

Nonsense!
An explicit cast on the value returned from malloc
is *not* explicitly os implicitly prohibited by the ANSI/ISO C standards
and there is *no* C compiler that will complain about it.

Who said anything about using malloc in C++?
I'm just using my C++ compiler to compile C code.

The important thing here is to adopt a style and stick to it.

True but this is not a style issue.

If it isn't a style issue, then it is nothing at all.

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in
news:40**************@jpl.nasa.gov:

Mark A. Odell wrote:

It is not proper C.
Nonsense!
An explicit cast on the value returned from malloc
is *not* explicitly os implicitly prohibited by the ANSI/ISO C standards
and there is *no* C compiler that will complain about it.

It's not illegal, just not proper. Casts are a punt, you are side-stepping
the C type enforcement. In some cases you must do this (cast) but malloc()
is definitely not one of them.

Who said anything about using malloc in C++?
I'm just using my C++ compiler to compile C code.

Why when you can tell it to switch ISO C mode? Usually, just giving the
file a .c extension is all that is required. Otherwise, a flag is usually
available to force the file to be treated as C not C++.

The important thing here is to adopt a style and stick to it.

True but this is not a style issue.

If it isn't a style issue, then it is nothing at all.

Oh, it's still a punt.

--
- Mark ->
--

"E. Robert Tisdale" wrote:

Mark A. Odell wrote:

It is not proper C.
Nonsense!
An explicit cast on the value returned from malloc
is *not* explicitly os implicitly prohibited by the ANSI/ISO C standards
and there is *no* C compiler that will complain about it.

"Not proper" is perhaps too strong. "Not useful" or
"not needed" or "not smart" might have been better.
Who said anything about using malloc in C++?
I'm just using my C++ compiler to compile C code.

It's not C code if it's being compiled as C++. Perhaps
you could clarify with a simple test:

#include <stdio.h>
typedef int private;
private main(private class, char **new) {
puts ("Hello, world!");
return 0;
}

If your implementation fails to compile and run this program,
the code is not being processed as C but as something else.

--
Er*********@sun.com

Eric Sosman wrote:

Perhaps you could clarify with a simple test:

#include <stdio.h>
typedef int private;
private main(private class, char **new) {
puts ("Hello, world!");
return 0;
}

If your implementation fails to compile and run this program,
the code is not being processed as C but as something else. cat main.c #include <stdio.h>

typedef int private;
private main(private class, char* new[]) {
puts("Hello, world!");
return 0;
}
g++ -x c++ -Dprivate=Private -Dclass=Class -Dnew=New \ -Wall -ansi -pedantic -o main main.c
main.c:4: warning: return type for `main' changed to `int' ./main Hello, world! gcc -x c -Dprivate=Private -Dclass=Class -Dnew=New \ -Wall -std=c99 -pedantic -o main main.c ./main

Hello, world!

"E. Robert Tisdale" wrote:

Eric Sosman wrote:

Perhaps you could clarify with a simple test:

#include <stdio.h>
typedef int private;
private main(private class, char **new) {
puts ("Hello, world!");
return 0;
}

If your implementation fails to compile and run this program,
the code is not being processed as C but as something else.

> cat main.c

#include <stdio.h>

typedef int private;
private main(private class, char* new[]) {
puts("Hello, world!");
return 0;
}

> g++ -x c++ -Dprivate=Private -Dclass=Class -Dnew=New \

-Wall -ansi -pedantic -o main main.c
main.c:4: warning: return type for `main' changed to `int'

> ./main

Hello, world!

> gcc -x c -Dprivate=Private -Dclass=Class -Dnew=New \

-Wall -std=c99 -pedantic -o main main.c

> ./main

Hello, world!

Care to try it again without the -D switches?

Here's the point I'm trying to make: The meaning of a source
file is not contained within the file itself, but only arises
when the file is handed to a compiler or interpreter or whatever.
A C compiler treats the source handed to it as C code; hand that
same source to a C++ compiler and it's C++ code. Hand it to a
COBOL compiler and it's COBOL code.

I once saw an ingeniously constructed source file that
implemented "Hello, world!" in three languages at once: C (pre-
Standard), Fortran (flavor unremembered), and csh. And in natural
languages we have the example of "Mots D'Heures, Gousses, Rames,"
a text that is simultaneously stilted French and phonetic English.
Such exercises, although entertaining and perhaps awe-inspiring,
are not especially practical.

Ordinarily, it's difficult to prepare a source file that's
meaningful in two or more different languages, and even more
difficult to get the different languages to assign the source the
same meaning. But because C and C++ diverged fairly recently,
they have enough in common that it's still possible to write such
ambivalent code fragments. "Possible" doesn't mean "Recommended"
or even "Sane," though: The writing is noticeably cramped, even
if not as perversely contorted as the ForcshtranC tour de farce.
Some may find it amusing to write such hermaphroditic code, but
a recommendation for or against a particular coding practice
should arise from something more than entertainment potential.

Do not pretend that C and C++ are interchangeable, even in
subsetted forms. They are closely related but different languages,
and the attempt to write ambivalent code gives a product that is
neither good C nor good C++. Choose your language and use it to
the hilt; there is no reason to weaken your code with compromise.

--
Er*********@sun.com

Eric Sosman wrote:

Here's the point I'm trying to make:

[snip]

The point is that nobody claimed that,
"Every C program is a C++ program".

I can't afford to write C code
that cannot also be compiled by a C++ compiler.
We can't afford to support two versions of libraries
one for C programs and another for C++ programs.
We just write code that will compile as either one.

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:40**************@jpl.nasa.gov...

Eric Sosman wrote:

Here's the point I'm trying to make:

[snip]

The point is that nobody claimed that,
"Every C program is a C++ program".

I can't afford to write C code
that cannot also be compiled by a C++ compiler.
We can't afford to support two versions of libraries
one for C programs and another for C++ programs.
We just write code that will compile as either one.

Why? Any C compiler suite worth it's bones can compile C code even if it
can also compile C++. Hint: MSVC which is called a C++ compiler can
compile ANSI C [C89 I think] when the filename ends with ".c". Similar for
GCC....

So you really ought to write code that either builds with a "C Compiler" or
a "C++ Compiler" [or just get better tools that can build either].

Tom

Stroutstrup himself has said that all good-style C programs are also C++
programs, so it's just better style. Also, we're not limited to malloc()
here, what if you wrote your own function that returns a generic pointer.
Thirdly, it's always best to be explicit. Lastly, it provides compatibility
with older compilers.

Tom St Denis wrote:

Any C compiler suite worth it's bones can compile C code
even if it can also compile C++.
MSVC, which is called a C++ compiler, can compile ANSI C [C89 I think]
when the filename ends with ".c".
Similar for GCC....

So you really ought to write code
that either builds with a "C Compiler" or a "C++ Compiler"
[or just get better tools that can build either].

We distribute software packages as source code
which must port to a variety of different platforms.
Our distribution is *much* less attractive
if users must buy and/or install companion C and C++ compilers
before they can actually build the package.

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:40**************@jpl.nasa.gov...

Tom St Denis wrote:

Any C compiler suite worth it's bones can compile C code
even if it can also compile C++.
MSVC, which is called a C++ compiler, can compile ANSI C [C89 I think]
when the filename ends with ".c".
Similar for GCC....

So you really ought to write code
that either builds with a "C Compiler" or a "C++ Compiler"
[or just get better tools that can build either].

We distribute software packages as source code
which must port to a variety of different platforms.
Our distribution is *much* less attractive
if users must buy and/or install companion C and C++ compilers
before they can actually build the package.

My point is many compiler suites have BOTH. It just doesn't make sense to
write only a C++ compiler [and not support the few differences in C]. This
is the case for Borland, Microsoft, [iirc] Watcom and GNU compiler suites.

So write portable C code that doesn't use any platform specific headers,
features, or extensions and you're set.

E. Robert Tisdale wrote:

Tom St Denis wrote:

Any C compiler suite worth it's bones can compile C code
even if it can also compile C++.
MSVC, which is called a C++ compiler, can compile ANSI C [C89 I think]
when the filename ends with ".c".
Similar for GCC....

So you really ought to write code
that either builds with a "C Compiler" or a "C++ Compiler"
[or just get better tools that can build either].

We distribute software packages as source code
which must port to a variety of different platforms.
Our distribution is *much* less attractive
if users must buy and/or install companion C and C++ compilers
before they can actually build the package.

Tisdale, tell us why we should care about your broken packages,
nonsensical source code, moronic comments, or the broken compiler suites
of your clients. Tell us why comp.lang.c, a group devoted to the
discussion of standard C, should be burdened by your travails or your
nonsense.

Or, better yet, don't. Just leave, and make no comment upon your departure.

--
My address is yvoregnevna gjragl-guerr gjb-gubhfnaq guerr ng lnubb qbg pbz
Note: Rot13 and convert spelled-out numbers to numerical equivalents.

"Mark A. Odell" <no****@embeddedfw.com> wrote in message
news:Xn********************************@130.133.1. 4...

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in
news:40**************@jpl.nasa.gov:

I saw on a couple of recent posts
people saying that casting the return value of malloc is bad, like:

double* p = (double*)malloc(50*sizeof(double));

Why is this bad?
It isn't.

It is not proper C.

What is proper C (sic)? Is it anything like baroque C?
To the OP, ignore E. Robert Tisdale's response
and read the C-FAQ instead.

Which part? [Have you read 2.14 recently?]

I had always thought (perhaps mistakenly) that
the purpose of a void pointer was to cast into a legitimate date type.
Is this wrong?

No.

It is.

The purpose of a void pointer is to implement a generic pointer implicitly
convertable to (almost) any other pointer type.

Why and what is considered to be correct form?

This is just a style issue.

It is not.

Then what is it? Feng Shui?

If you think it's a correctness issue, then please provide C&V definitively
proving that the casting of malloc precludes the production of strictly
conforming programs in C.

The important thing here is to adopt a style and stick to it.

True but this is not a style issue.

Yes it is. It wasn't once, then it became one with the first standard, and
now it will probably always remain one.

--
Peter

"Peter Nilsson" <ai***@acay.com.au> wrote in message
news:40******@news.rivernet.com.au...

"Mark A. Odell" <no****@embeddedfw.com> wrote in message
news:Xn********************************@130.133.1. 4...

....

To the OP, ignore E. Robert Tisdale's response
and read the C-FAQ instead.

Which part? [Have you read 2.14 recently?]

Obviously I haven't! I meant 6.16, but Steve removed the casted malloc from
the FAQ since I last glanced at it.

Nonetheless, neither 7.6 nor 7.7 actually state that it is wrong to cast
malloc.

--
Peter

"Peter Nilsson" <ai***@acay.com.au> wrote in message
news:40******@news.rivernet.com.au...

I meant 6.16, but Steve removed the casted malloc from
the FAQ since I last glanced at it.

Ah, unless I'm having caching problems, he still has the casted form in...

http://www.eskimo.com/~scs/C-faq/q6.16.html

--
Peter

Peter Nilsson wrote:

Peter Nilsson wrote:

I meant 6.16, but Steve removed the casted malloc from
the FAQ since I last glanced at it.

Ah, unless I'm having caching problems, he still has the casted form in...

http://www.eskimo.com/~scs/C-faq/q6.16.html

That's what I see.

Mark Bruno wrote:

Stroutstrup himself has said that all good-style C programs are also C++
programs,
What he actually said was: "However, /good/ C programs *tend* to be C++
programs". And that's partly wrong (because there are plenty of good C
programs that haven't got a hope of compiling in C++), and partly silly
(because even if they /do/ manage to compile as C++, it won't be /good/
C++).
so it's just better style.
No, bodging C programs so that they compile in C++ can no more count as
"better style" than bodging C programs so that they compile in C++.
Also, we're not limited to malloc()
here, what if you wrote your own function that returns a generic pointer.
I have written such functions. I don't cast when calling them. Why on earth
should I?
Thirdly, it's always best to be explicit.
Are you sure?

#include <stdio.h>

int main(void)
{
int x = (int)6;
int y = (int)42;
(int)printf((const char *)"%d\n", (int)((int)x+(int)y));
return (int)0;
}

Do you really write your code like that?
Lastly, it provides
compatibility with older compilers.

Do you write your function declarators like this?

foo(a, b)
int a;
double b;
{
/* function goes here */

What does C++ think about that?

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

"Peter Nilsson" <ai***@acay.com.au> wrote:

"Peter Nilsson" <ai***@acay.com.au> wrote in message
news:40******@news.rivernet.com.au...

I meant 6.16, but Steve removed the casted malloc from
the FAQ since I last glanced at it.

Ah, unless I'm having caching problems, he still has the casted form in...

http://www.eskimo.com/~scs/C-faq/q6.16.html

FWIW, in the plain text version of the FAQ (that I downloaded
weeks ago from faqs.org, IIRC) I fail to find a single occurrence
of a casted malloc return value - throughout the entire document.

The text version appears to be more up to date than the hypertext
rendition; see Steve Summit's comments in:

http://www.eskimo.com/~scs/C-faq/versions.html

Regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc : http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.eskimo.com/~scs/C-faq/top.html
acllc-c++ faq : http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

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

We can't afford to support two versions of libraries
one for C programs and another for C++ programs.
We just write code that will compile as either one.

<OT>
C++ has a standardized way to interface with C code.
</OT>

Martin

On Fri, 23 Jan 2004 20:36:19 -0500, in comp.lang.c , "Mark Bruno"
<ya*************@yahoo.com> wrote:

Stroutstrup himself has said that all good-style C programs are also C++
programs, so it's just better style.
Well, either you misinterpret him, or he's wrong.

int main(void)
{
int new;
double *x = malloc(12);
}

There's nothing at all stylistically wrong with this C programme but
its not likely to be a C++ one.
Also, we're not limited to malloc()here, what if you wrote your own function that returns a generic pointer.
Not a problem for C.
Thirdly, it's always best to be explicit.
For me, its totally obvious what int *p = malloc(12) is doing. Adding
casts merely makes if obfuscated and more error prone.
Lastly, it provides compatibility
with older compilers.

This argument would cause you to remove all templates from your C++.
IOW, its bullsh*t

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

Mark A. Odell wrote:

Brian Blais <bb****@bryant.edu> wrote in news:40************@bryant.edu:

Hello,

I saw on a couple of recent posts people saying that casting the return
value of malloc is bad, like: d=(double *) malloc(50*sizeof(double));

See the C-FAQ as to why.

http://www.eskimo.com/~scs/C-faq/q7.6.html
http://www.eskimo.com/~scs/C-faq/q7.7.html

Neither of these gives a proper "why".

Section 7.7 comes closest:

"Q. Why does some code carefully cast the values returned by malloc to
the pointer type being allocated?

A. Before ANSI/ISO Standard C introduced the void * generic pointer
type, these casts were typically required to silence warnings (and
perhaps induce conversions) when assigning between incompatible pointer
types. (Under ANSI/ISO Standard C, these casts are no longer necessary.)"

This is a strawman argument: "people using casted mallocs are adhering
to a prehestoric style". Most people that do cast malloc() results
nowadays have other reasons.

If the FAQ is to properly reflect the CLC opinion, it should at least
mention the counter-argument that failing to cast malloc prevents a C++
compiler from having a fighting chance at compiling your code.

For all I care, the FAQ could then go on to explain why this is such a
monumentally silly idea (which I don't think it is, of course).

At least, the presentation of the issue would then be honest. Right now,
it is an over-simplification of a complicated issue where there are
really two sides, I think.

Best regards,

Sidney

"Default User" <fi********@boeing.com.invalid> wrote in message
news:40***************@boeing.com.invalid...

Mark Bruno wrote:

Casting of void* is required in C++, so i usually do it in C also. It's not
required, but it makes it easier when switching between C and C++, like I
often do.

You shouldn't be using malloc() in C++ period. Writing code to move back
and forth like that is poor idea. C++ is its own language, and you
should be writing C++ code using the modern libraries. Don't write
cripple C code for C++ applications.

I interpreted his remark as *not* writing code
that compiles for both C and C++, but that he
doesn't have to change his *style* for either
language.

Different languages often demand different
expressions of the same intent, thus different
styles of writing code.

On 23 Jan 2004 14:17:13 GMT, "Mark A. Odell" <no****@embeddedfw.com>
wrote in comp.lang.c:

Brian Blais <bb****@bryant.edu> wrote in news:40************@bryant.edu:

Hello,

I saw on a couple of recent posts people saying that casting the return
value of malloc is bad, like:

d=(double *) malloc(50*sizeof(double));

See the C-FAQ as to why.

http://www.eskimo.com/~scs/C-faq/q7.6.html
http://www.eskimo.com/~scs/C-faq/q7.7.html

why is this bad? I had always thought (perhaps mistakenly) that the
purpose of a void pointer was to cast into a legitimate date type.

Negative. Void pointers can hold any type of pointer so they naturally
"become" the desired type.

[snip]

ITYM "any type of object pointer".

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

On Fri, 23 Jan 2004 11:36:48 -0800, "E. Robert Tisdale"
<E.**************@jpl.nasa.gov> wrote in comp.lang.c:

Brian Blais wrote:

I saw on a couple of recent posts
people saying that casting the return value of malloc is bad, like:

double* p = (double*)malloc(50*sizeof(double));

Why is this bad?
It isn't.

I had always thought (perhaps mistakenly) that
the purpose of a void pointer was to cast into a legitimate date type.
Is this wrong?

No.

Why and what is considered to be correct form?

This is just a style issue.

By and large, the phrase "style issue" is a whine of unprofessional
and/or incompetent programmers.

Professional programmers work to meet requirements. Requirements
apply not only to the operation of the program, but also to the source
code.

Any reasonable set of programming requirements prohibits redundant
casts, as they are a source of coding defects and maintenance
problems.
I always use the explicit cast
to prevent my C++ compiler from complaining about
You are free to use anything you like in your code, provided it meets
the given requirements. If you are coding for yourself and the
requirements are your own, well and good. If you program
professionally for an organization that does not have formal
requirements, you are part of a group contributing to the sad state of
software development today.

As to what your C++ compiler complains about, that is of less than no
consequence, and off-topic, here. In this group, C++ literally does
not exist.
warning: invalid conversion from `void*' to `double*'
This is comp.lang.c, there is no such thing as an invalid conversion
from void* to double*. The conversion is implicit and correct.
It applies the implicit conversion anyway so it doesn't matter
except that more important warnings some times get lost
if too many warning messages such as this are issued by my compiler.

The important thing here is to adopt a style and stick to it.

People who use the term "style" actually do not understand the issues.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

"Jack Klein" <ja*******@spamcop.net> wrote in message
news:c2********************************@4ax.com...

warning: invalid conversion from `void*' to `double*'

This is comp.lang.c, there is no such thing as an invalid conversion
from void* to double*. The conversion is implicit and correct.

Nonsense. If the alignment is incorrect the conversion is invalid.
A compiler is not obliged to detect improper alignment, but if it
does, more power to it. (And this from a person who generally
dislikes warning messages.)

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

In article <bu**********@news.tudelft.nl>,
Sidney Cadot <si****@jigsaw.nl> wrote:

If the FAQ is to properly reflect the CLC opinion, it should at least
mention the counter-argument that failing to cast malloc prevents a C++
compiler from having a fighting chance at compiling your code.

Why should the C FAQ give a ratzass about C++ compilers. Sheesh.

--
"Well, coming from the AeroSpace Manufacturing field, I must add
that titanium is an alloy of aluminum, magnesium and other metals,
so I would assume since titanium is 65% magnesium that it would
react in a very similar manner."
Bill Garber in comp.sys.apple2 Posting-Date: Fri, 07 Feb 2003
03:02:11 -0600 Message-ID: <_E********************@comcast.com>

Jalapeno wrote:

In article <bu**********@news.tudelft.nl>,
Sidney Cadot <si****@jigsaw.nl> wrote:

If the FAQ is to properly reflect the CLC opinion, it should at least
mention the counter-argument that failing to cast malloc prevents a C++
compiler from having a fighting chance at compiling your code.

Why should the C FAQ give a ratzass about C++ compilers. Sheesh.

Is that a question or a statement?

Best regards,

Sidney

On Sat, 24 Jan 2004 19:00:24 GMT, in comp.lang.c , "P.J. Plauger"
<pj*@dinkumware.com> wrote:

"Jack Klein" <ja*******@spamcop.net> wrote in message
news:c2********************************@4ax.com.. .

> warning: invalid conversion from `void*' to `double*'
This is comp.lang.c, there is no such thing as an invalid conversion
from void* to double*. The conversion is implicit and correct.

Nonsense.

Hm?
If the alignment is incorrect the conversion is invalid.

But its impossible for it to be incorrect. The C Standard says so. If
your h/w platform can't guarantee it, then you can't implement C
there.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

On Sat, 24 Jan 2004 20:55:58 +0100, in comp.lang.c , Sidney Cadot
<si****@jigsaw.nl> wrote:

Jalapeno wrote:

In article <bu**********@news.tudelft.nl>,
Sidney Cadot <si****@jigsaw.nl> wrote:

If the FAQ is to properly reflect the CLC opinion, it should at least
mention the counter-argument that failing to cast malloc prevents a C++
compiler from having a fighting chance at compiling your code.

Why should the C FAQ give a ratzass about C++ compilers. Sheesh.

Is that a question or a statement?

Its an expression; :-)

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

On Sat, 24 Jan 2004 22:05:41 +0000, Mark McIntyre
<ma**********@spamcop.net> wrote:

On Sat, 24 Jan 2004 19:00:24 GMT, in comp.lang.c , "P.J. Plauger"
<pj*@dinkumware.com> wrote:

"Jack Klein" <ja*******@spamcop.net> wrote in message
news:c2********************************@4ax.com. ..

> warning: invalid conversion from `void*' to `double*'

This is comp.lang.c, there is no such thing as an invalid conversion
from void* to double*. The conversion is implicit and correct.

Nonsense.

Hm?

If the alignment is incorrect the conversion is invalid.

But its impossible for it to be incorrect. The C Standard says so. If
your h/w platform can't guarantee it, then you can't implement C
there.

I agree. I worked on a platform years ago that crashed if you accessed
any data type on a non-platform-natural boundary.

At the time -- working on a real world project -- this caused a load
of grief. I felt that the implementation should have provided the
required converions, and some kind of (compile time or run time)
warning that the code code could be inefficient, rather than simply
crashing during execution.

It's not exactly an easy problem for compiler writers, though.

- Sev

Martin Dickopp wrote:

<OT>
C++ has a standardized way to interface with C code.
</OT>

A common misconception.
C++ only has a mechanism (extern "C")
to *help* with linkage.
Neither C or C++ specifies interoperability.
In particular, any two different compilers
(even two different C compilers)
may use a different representation for built-in types,
may use a different protocol to pass arguments and return values,
etcetera.

"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:sv********************************@4ax.com...

On Sat, 24 Jan 2004 19:00:24 GMT, in comp.lang.c , "P.J. Plauger"
<pj*@dinkumware.com> wrote:

"Jack Klein" <ja*******@spamcop.net> wrote in message
news:c2********************************@4ax.com.. .

> warning: invalid conversion from `void*' to `double*'

This is comp.lang.c, there is no such thing as an invalid conversion
from void* to double*. The conversion is implicit and correct.

Nonsense.

Hm?

If the alignment is incorrect the conversion is invalid.

But its impossible for it to be incorrect. The C Standard says so. If
your h/w platform can't guarantee it, then you can't implement C
there.

Next step after nonsense -- bullshit. See 6.3.2.3, para. 7.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

> On Sat, 24 Jan 2004 22:05:41 +0000, Mark McIntyre

<ma**********@spamcop.net> wrote:

On Sat, 24 Jan 2004 19:00:24 GMT, in comp.lang.c , "P.J. Plauger"
<pj*@dinkumware.com> wrote:

"Jack Klein" <ja*******@spamcop.net> wrote in message
news:c2********************************@4ax.com. ..

> warning: invalid conversion from `void*' to `double*'

This is comp.lang.c, there is no such thing as an invalid conversion
from void* to double*. The conversion is implicit and correct.

Nonsense.
Hm?

If the alignment is incorrect the conversion is invalid.

But its impossible for it to be incorrect.
The C Standard says so. ...

I'm sure Plauger is more than aware of what the C standard(s) say on the
issue! ;)

The return value for [re|c|m]alloc is correctly aligned for all types,
however, in general, the conversion itself in general is not guaranteed to
be aligned...

char c[sizeof(double)];
void *vp = c;
double *dp = vp; /* potential UB */
"Severian" <se******@chlamydia-is-not-a-flower.com> wrote in message
news:vn********************************@4ax.com... I agree. I worked on a platform years ago that crashed if you accessed
any data type on a non-platform-natural boundary.
They are not uncommon.
At the time -- working on a real world project -- this caused a load
of grief. I felt that the implementation should have provided the
required converions, and some kind of (compile time or run time)
warning that the code code could be inefficient, rather than simply
crashing during execution.
Implementations are quite limited in being able to repair the damage of bad
source code and practices (see above example). Do you have examples of what
the 'required conversions' should be, and the contexts in which they might
be 'useful'?
It's not exactly an easy problem for compiler writers, though.

Quite! :-)

--
Peter

"Jack Klein" <ja*******@spamcop.net> wrote in message
news:c2********************************@4ax.com...

On Fri, 23 Jan 2004 11:36:48 -0800, "E. Robert Tisdale"
<E.**************@jpl.nasa.gov> wrote in comp.lang.c:

Brian Blais wrote:

I saw on a couple of recent posts
people saying that casting the return value of malloc is bad, like:

double* p = (double*)malloc(50*sizeof(double));

Why is this bad?

It isn't.

I had always thought (perhaps mistakenly) that
the purpose of a void pointer was to cast into a legitimate date type.
Is this wrong?

No.

Why and what is considered to be correct form?

This is just a style issue.

By and large, the phrase "style issue" is a whine of unprofessional
and/or incompetent programmers. ...

You left out a slur on business acumen.

--
Peter

P.J. Plauger wrote:

"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:sv********************************@4ax.com...

On Sat, 24 Jan 2004 19:00:24 GMT, in comp.lang.c , "P.J. Plauger"
<pj*@dinkumware.com> wrote:

"Jack Klein" <ja*******@spamcop.net> wrote in message
news:c2********************************@4ax.com ...
>warning: invalid conversion from `void*' to `double*'

This is comp.lang.c, there is no such thing as an invalid conversion
from void* to double*. The conversion is implicit and correct.

Nonsense.

Hm?

If the alignment is incorrect the conversion is invalid.

But its impossible for it to be incorrect. The C Standard says so. If
your h/w platform can't guarantee it, then you can't implement C
there.

Next step after nonsense -- bullshit. See 6.3.2.3, para. 7.

I seems to me that Mark McIntyre is right. The para 7 cited by P.J.
Plauger says:

"A pointer to an object or incomplete type may be converted to a pointer
to a different object or incomplete type. If the resulting pointer is not
correctly aligned for the pointed-to type, the behavior is undefined.
Otherwise, when converted back again, the result shall compare equal to
the original pointer. [...]"

Para 1 of the same section says:

"A pointer to void may be converted to or from a pointer to any incomplete
or object type. A pointer to any incomplete or object type may be converted
to a pointer to void and back again; the result shall compare equal to the
original pointer."

So: para 1 says the void -> double pointer conversion is guaranteed to
produce a correct "round trip", while para 7 states that pointer conversion
*in general* will fail to produce a correct round trip in the case of
misalignment. It follows that misalignment is stipulated to be
impossible in the void -> double case.

--
Allin Cottrell
Department of Economics
Wake Forest University, NC

On Sun, 25 Jan 2004 12:04:29 +1100, "Peter Nilsson"
<ai***@acay.com.au> wrote:

On Sat, 24 Jan 2004 22:05:41 +0000, Mark McIntyre
<ma**********@spamcop.net> wrote:

>On Sat, 24 Jan 2004 19:00:24 GMT, in comp.lang.c , "P.J. Plauger"
><pj*@dinkumware.com> wrote:
>
>>"Jack Klein" <ja*******@spamcop.net> wrote in message
>>news:c2********************************@4ax.com. ..
>>
>>> > warning: invalid conversion from `void*' to `double*'
>>>
>>> This is comp.lang.c, there is no such thing as an invalid conversion
>>> from void* to double*. The conversion is implicit and correct.
>>
>>Nonsense.
>
>Hm?
>
>> If the alignment is incorrect the conversion is invalid.
>
>But its impossible for it to be incorrect.
>The C Standard says so. ...
I'm sure Plauger is more than aware of what the C standard(s) say on the
issue! ;)

The return value for [re|c|m]alloc is correctly aligned for all types,
however, in general, the conversion itself in general is not guaranteed to
be aligned...

char c[sizeof(double)];
void *vp = c;
double *dp = vp; /* potential UB */ "Severian" <se******@chlamydia-is-not-a-flower.com> wrote in message
news:vn********************************@4ax.com.. .

I agree. I worked on a platform years ago that crashed if you accessed
any data type on a non-platform-natural boundary.

They are not uncommon.

I know better now; this was ca. 1990.
At the time -- working on a real world project -- this caused a load
of grief. I felt that the implementation should have provided the
required converions, and some kind of (compile time or run time)
warning that the code code could be inefficient, rather than simply
crashing during execution.

Implementations are quite limited in being able to repair the damage of bad
source code and practices (see above example). Do you have examples of what
the 'required conversions' should be, and the contexts in which they might
be 'useful'?

Well, after we had fixed all the crappy code, we found a compiler
option that would include runtime code to work around alignment
errors. We pulled the original code and ran it; it was something like
40x slower than the fixed code.

It's not exactly an easy problem for compiler writers, though.

Quite! :-)

I learned a lot that year!

- Sev

Allin Cottrell wrote:

P.J. Plauger wrote:

"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:sv********************************@4ax.com...

On Sat, 24 Jan 2004 19:00:24 GMT, in comp.lang.c , "P.J. Plauger"
<pj*@dinkumware.com> wrote:

"Jack Klein" <ja*******@spamcop.net> wrote in message
news:c2********************************@4ax.co m...
>>warning: invalid conversion from `void*' to `double*'
>
>This is comp.lang.c, there is no such thing as an invalid conversion
>from void* to double*. The conversion is implicit and correct.

Nonsense.

Hm?

If the alignment is incorrect the conversion is invalid.

But its impossible for it to be incorrect. The C Standard says so. If
your h/w platform can't guarantee it, then you can't implement C
there.

Next step after nonsense -- bullshit. See 6.3.2.3, para. 7.

I seems to me that Mark McIntyre is right.

It seems to /me/ that they are both right, because they are answering
different questions. Mark quite rightly assumes that nobody would be so
stupid as to attempt to perform a conversion such as:

char buf[] = "12345.678";
void *p = buf;
double *d = p; /* Don't Do This */
printf("%f\n", *d); /* And REALLY REALLY Don't Do THIS */

Whereas P J Plauger quite rightly assumes that some people /would/ be so
stupid.

If my supposition is true, it could certainly explain why they are both so
convinced they're correct. It would also suggest that Mr Plauger owes Mr
McIntyre and Mr Klein an apology. It is quite plain that neither Jack nor
Mark spoke nonsense, if one only takes a few seconds out to work out the
logic behind their answers.

Note, also, that the cast (remember that?) doesn't help in this situation.
If you try to convert an undoublypointery thing into a doublypointerything
by going via void *, the cast will not magically supply this conversion for
you.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton