why is casting malloc a bad thing?

[Tom St Denis]

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

 

[E. Robert Tisdale]

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.

 

[Mark Bruno]

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]

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.

 

[August Derleth]

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.

 

[Peter Nilsson]

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?]

It is.

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

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.

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 Nilsson]

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 Nilsson]

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

 

[E. Robert Tisdale]

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.

 

[Richard Heathfield]

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?

 

[Irrwahn Grausewitz]

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

 

[Martin Dickopp]

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

 

[Mark McIntyre]

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

 

[Sidney Cadot]

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

 

[xarax]

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.

 

[Jack Klein]

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


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]

It isn't.


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.

 

[P.J. Plauger]

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

 

[Jalapeno]

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: <[email protected]>

 

[Sidney Cadot]

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

Is that a question or a statement?

Best regards,

Sidney