Common misconceptions about C (C95)

[Richard Tobin]

C++ NEEDS the cast... If you ever want to compile your code in C++ mode
it is better to leave the cast there.

I doubt I will ever want to. I usually try to make my header files
includable in C++, but the executable C code whould just be compiled
as C.

-- Richard

 

[Ioannis Vranos]

Richard Tobin a écrit :

C++ NEEDS the cast... If you ever want to compile your code in C++ mode
it is better to leave the cast there.

If you want to use C code with C++ code, there is

extern "C".


Otherwise, converting C code to C++ will be messy.


Also, why convert C code to C++? It will be tiresome. There are subtle
differences, like sizeof('a') being different in C and C++, etc..




--
Ioannis Vranos

C95 / C++03 Software Developer

http://www.cpp-software.net

 

[gwowen]

In short, it's bad form to call functions without a prototype.

So if I use a C99-mode compiler (or -Wmissing-prototypes or
equivalent), the major (sole?) reason for not casting vanishes, right?

 

[Kenny McCormack]

So if I use a C99-mode compiler (or -Wmissing-prototypes or
equivalent), the major (sole?) reason for not casting vanishes, right?

You are not allowed to discuss C99 in CLC...

Seriously, the "not casting the return value of malloc()" shibboleth
arose mainly out of C89 considerations (the only version approved by
alpha male Dicky H).

 

[Keith Thompson]

Precisely. That's why it belongs on a list of misconceptions.

Michael Tsang was claiming that the use of malloc without a cast *is*
considered poor practice. Seebs was disagreeing with him (as did I).

Ioannis's web page itself says:

| Misconception 10: Invokations of malloc(), calloc(), and realloc(),
| need casting.
....
| Clarification: Casting is not needed
....

 

[spinoza1111]

You are not allowed to discuss C99 in CLC...

Seriously, the "not casting the return value of malloc()" shibboleth
arose mainly out of C89 considerations (the only version approved by
alpha male Dicky H).

Sounds to me idiotic not to cast. Strong typing better than weak
typing. But the cool, studly kids don't cast. I cast because I'm good
at C and I don't even use it much (which is a sign of a programmer
who's good at C, paradoxically enough).

 

[Keith Thompson]

So if I use a C99-mode compiler (or -Wmissing-prototypes or
equivalent), the major (sole?) reason for not casting vanishes, right?

No.

First of all, C99 removed implicit int, but it still doesn't require
prototypes. That's probably not relevant in this case, since you
still need a visible declaration that specifies the return type.

The real reason not to cast the result of malloc is that *the cast
has no benefit* (except in the rare case where you want to compile
the same code as C and as C++).

I can write:

ptr = malloc(count * sizeof *ptr);

The code is perfectly clear to anyone who knows the language well
enough, and it works. Adding a cast, in the best case, simply adds
information that the compiler already knows. Why bother?

Would you use a cast for this?

float x = (float)sqrt(2.0);

I wouldn't, because it's unnecessary.

 

[Richard Tobin]

Sounds to me idiotic not to cast. Strong typing better than weak
typing.

Casting is a way to defeat strong typing.

int a;
char *p;
...
p = a;

This is an error requiring a diagnostic.

int a;
char *p;
...
p = (char *)a;

This is not. The cast tells the compiler *not* to apply its usual
strong typing, but to convert the value to a character pointer
regardless.

-- Richard

 

[Richard Tobin]

If you want to use C code with C++ code, there is

extern "C".

Otherwise, converting C code to C++ will be messy.

Also, why convert C code to C++? It will be tiresome. There are subtle
differences, like sizeof('a') being different in C and C++, etc..

If I understand correctly, 'extern "C"' is not for converting arbitrary
C code to C++, but merely to tell the C++ compiler that the contained
declarations are for C functions. Interfacing C++ to C functions is
quite a different matter from compiling executable C code as C++.

-- Richard

 

[Ioannis Vranos]

Why is it double- (and sometimes triple- and quadruple-) spaced? That
makes it hard to follow.

The page looks OK in my laptop (1920x1080 resolution).

The license section (about 60% of the bulk of the document) is a
distraction. Why not just make it a link.

The license must be included in the document to be in effect.



--
Ioannis Vranos

C95 / C++03 Software Developer

http://www.cpp-software.net

 

[Ioannis Vranos]

I have created a text available under GNU FDL 3 (Free Documenation
License) or later, regarding "Common misconceptions about C" (C95).


http://www.cpp-software.net/documents/free_documents/c_misconceptions.html


Any constructive comments/error corrections are welcome.

I have uploaded a corrected version of the page.


Any constructive comments/error corrections are welcome.



http://www.cpp-software.net/documents/free_documents/c_misconceptions.html



--
Ioannis Vranos

C95 / C++03 Software Developer

http://www.cpp-software.net

 

[Ioannis Vranos]

10. Use of malloc without casting is considered a poor practice (it is an
error in C++). Cast it to suitable type instead.

C and C++ are different languages.



--
Ioannis Vranos

C95 / C++03 Software Developer

http://www.cpp-software.net

 

[Nobody]

No, casting the result of malloc is considered poor practice in C.
This is covered in the comp.lang.c FAQ, <http://www.c-faq.com>.

Considered by whom?

I've heard reasonable arguments both for and against. OTOH, I've never
seen evidence (e.g. a survey) that either approach could be considered a
consensus viewpoint.

 

[Ioannis Vranos]

Considered by whom?

I've heard reasonable arguments both for and against. OTOH, I've never
seen evidence (e.g. a survey) that either approach could be considered a
consensus viewpoint.

Since the casting is not needed, using it is a bad style. At least, it shows
that there is luck of C knowledge.



--
Ioannis Vranos

C95 / C++03 Software Developer

http://www.cpp-software.net

 

[Ioannis Vranos]

Since the casting is not needed, using it is a bad style. At least, it

shows that there is lack of C knowledge.




--
Ioannis Vranos

C95 / C++03 Software Developer

http://www.cpp-software.net

 

[Nobody]

In short, it's bad form to call functions without a prototype.

Which is why compilers will typically warn you if you do so.

You don't need to rely upon an "implicit conversion" warning when a more
specific warning is available.

If you omit the prototype on a system where sizeof(void*)!=sizeof(int),
you'll end up with broken object code with or without the cast.

IOW, omitting the cast doesn't really buy you anything worthwhile. OTOH,
including the cast makes it easier to visually catch cases such as:

struct foo *p;

/* one million LoC later */

p = (struct foo *) malloc(n * sizeof(struct bar));

 

[Ioannis Vranos]

And you posted that why?

Because you said we should cast in C, because using malloc() needs a casting
in C++, where using malloc() is considered poor practice.



--
Ioannis Vranos

C95 / C++03 Software Developer

http://www.cpp-software.net

 

[Ioannis Vranos]

IOW, omitting the cast doesn't really buy you anything worthwhile. OTOH,
including the cast makes it easier to visually catch cases such as:

struct foo *p;

/* one million LoC later */

p = (struct foo *) malloc(n * sizeof(struct bar));

p= malloc(n* sizeof(*p));




--
Ioannis Vranos

C95 / C++03 Software Developer

http://www.cpp-software.net

 

[Nobody]

Casting is a way to defeat strong typing.

int a;
char *p;
...
p = a;

This is an error requiring a diagnostic.

But we were discussing casting a "void*", which is C's own opt-out of
static typing.

C doesn't care about either implicit or explicit casts of void* to other
pointers. An explicit cast at least provides a visual cue as to the
intent, and will even produce a diagnostic if you explicitly cast to the
wrong type, e.g.:

struct foo *p;
struct bar *q;
void *x;

p = x; /* no diagnostic */
p = (struct bar *) x; /* diagnostic */

 

[Ioannis Vranos]

Because you said we should cast in C, because using malloc() needs a
casting in C++, where using malloc() is considered poor practice.

More accurately bad style. Since malloc(), calloc()/free() do not invoke
object constructors/destructors respectively.


--
Ioannis Vranos

C95 / C++03 Software Developer

http://www.cpp-software.net