C/C++ guidelines

J

Joachim Schmitz

Joachim Schmitz said:
Peter J. Holzer said:
//c-faq.com/malloc/mallocnocast.html[/url]

Thanx. Though I don't buy in that "argument".

Consider:

#include <stdio.h>

int main(void)
{
char *p = (char *) malloc(10);

return 0;
}

At least lcc-win32 DOES warn you: "Missing prototype for 'malloc'.

Same with Pelles C: "Missing prototype for 'malloc'".

Same with gcc: "implicit declaration of function 'malloc'".

Once upon a time most compilers didn't warn about missing prototypes but
they did warn about conversions from int to a pointer. In these days not
casting malloc was the most reliable way to catch a missing declaration
of malloc.
Because they are required to do diagnose the conversionm and free to do do
the same with the missing prototype
oops, spelling/typing problems, sorry...
Because they are required to diagnose the conversion and free to diagnose
the missing prototype
 
J

Joachim Schmitz

Harald van D?k said:
It is not in C90, but it is in C99.
Chapter and Verse?

However, not using the case it still the safe bet, given the not so wide
choice of C99 compilers
 
K

Karl Heinze

[...] in C you should not cast the result of malloc, because
doing that might introduce subtle errors [...]
For example?
Failure to #include <stdlib.h> going undetected.
Huh?

So it's _not_ the usage of the cast (as such) which "might introduce
subtle errors" but forgetting to include <stdlib.h>.

On the other hand most modern C compilers (as it seems) would catch
that lapse (and produce a warning). (At least this is true for the C
compilers _I_ use: lcc-win32, Pelles C, gcc.)


K. H.
 
W

Wade Ward

Keith Thompson said:
Consider programming in C90 and making sure not to accidentally use a
C++ compiler. You can enforce this with:

#ifdef __cplusplus
#error "Use a C compiler, not a C++ compiler"
#endif
Keith's right here.

Mr. Thompson has called me a troll, a curious appellation for a large,
jellyfilled donut whose first german language book was Gödel, Escher, Bach.
Was ist die Abbildung an Bloop, Floop, und Gloop?
 
?

=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F

Chapter and Verse?

C99 has no implicit function declarations.

6.5.1p2:
"An identifier is a primary expression, provided it has been declared as
designating an object (in which case it is an lvalue) or a function (in
which case it is a function designator). 76)"

Footnote 76:
"Thus, an undeclared identifier is a violation of the syntax."

A diagnostic is required (in both C90 and C99) for all syntax errors.
However, not using the case it still the safe bet, given the not so wide
choice of C99 compilers

Using malloc without a proper declaration would result in a warning
message from my compiler even in C90 mode. If yours doesn't at least have
an option to warn about implicit function declarations, though, then yes,
it would be better for you not to cast malloc's result. For me, it
wouldn't matter.
 
K

Karl Heinze

There is STILL something wrong with casting malloc's return value:
It is unnecessary and clutters up the code.
Actually, I already found that habit (casting malloc's return value)
described as _good coding practice_.


K. H.
 
K

Karl Heinze

Nonsense. In the cases where the code is broken with the cast, it's also
broken without the cast, and the argument about hiding a missing
inclusion of <stdlib.h> only applies if the programmer uses a compiler
that won't warn on implicit function declarations. Mine does, so how
would it be dangerous for me to cast the result of malloc?
Completely agree with you. Moreover, if C99 is actually required to
produce a warning in case of an implicit declared function (as you
claimed) this silly argument (in the C-FAQ) is completely disproved.


K. H.
 
J

Joachim Schmitz

Harald van D?k said:
C99 has no implicit function declarations.

6.5.1p2:
"An identifier is a primary expression, provided it has been declared as
designating an object (in which case it is an lvalue) or a function (in
which case it is a function designator). 76)"

Footnote 76:
"Thus, an undeclared identifier is a violation of the syntax."
OK, thanks. Are footnotes normative?
A diagnostic is required (in both C90 and C99) for all syntax errors.


Using malloc without a proper declaration would result in a warning
message from my compiler even in C90 mode. If yours doesn't at least have
an option to warn about implicit function declarations, though, then yes,
it would be better for you not to cast malloc's result. For me, it
wouldn't matter.
The compilers I use warn too (with appropriate warning level set), but they
are not required too and that's the whole point.
 
K

Karl Heinze

The compilers I use warn too (with appropriate warning level set), but they
are not required too and that's the whole point.
Clearly the "problem" is NOT the usage of a cast (which is required in
C++ !) but forgetting to include <stdlib.h>.


K. H.
 
C

Chris Hills

Robbie Marshall said:
Hi groups,

I'm about to embark on a new project and for maximum portability we've
been asked to code it in the common subset of C and C++.

Can anyone suggest any good documents that might help us? Lists of
gotchas to avoid, that sort of thing?

Firstly what are the compilers and targets?

Due to the lack of serious take up of the current C99 standard and many
compiler having compiler and target extensions (also domain extensions)
it is better to start with the tools than the standard.

You have asked a practical not theoretical question.
 
?

=?iso-2022-kr?q?Harald_van_D=0E=29=26=0Fk?=

OK, thanks. Are footnotes normative?

No, they are not. However, this footnote is a correct conclusion from the
normative text that references it.
The compilers I use warn too (with appropriate warning level set), but
they are not required too and that's the whole point.

Oh? I thought the point was so that you, the programmer, can figure out
where your bugs are. If someone else wants to compile the code with a
compiler that doesn't warn on implicit malloc declarations, they can,
because you've already made sure to include <stdlib.h> after the warnings
you were getting.
 
J

Jim Langston

Wade Ward said:
Keith's right here.

Mr. Thompson has called me a troll, a curious appellation for a large,
jellyfilled donut whose first german language book was Gödel, Escher,
Bach. Was ist die Abbildung an Bloop, Floop, und Gloop?

Ummm.. how do you take his response as him calling you a troll? His
response was appropriate and gave some good advice.

Seeing how you seem to think that's calling you a troll makes me think that
maybe you are.
 
J

Joachim Schmitz

Karl Heinze said:
Clearly the "problem" is NOT the usage of a cast (which is required in
C++ !) but forgetting to include <stdlib.h>.
What has C++ got to do with this?

Indeed the probem is the missing prototype, but C-Compilers don't have to
warn about that and they can't warn about type conversion if there's a cast,
so "defensive programming" mandates not to use the cast.
The cast _may_ hide a bug, not using it _will_ prevent it.
 
P

Peter J. Holzer

Joachim Schmitz said:
Peter J. Holzer said:
//c-faq.com/malloc/mallocnocast.html[/url]

Thanx. Though I don't buy in that "argument". [...]
At least lcc-win32 DOES warn you: "Missing prototype for 'malloc'.

Same with Pelles C: "Missing prototype for 'malloc'".

Same with gcc: "implicit declaration of function 'malloc'".

Once upon a time most compilers didn't warn about missing prototypes but
they did warn about conversions from int to a pointer. In these days not
casting malloc was the most reliable way to catch a missing declaration
of malloc.
Because they are required to do diagnose the conversionm and free to do do
the same with the missing prototype
oops, spelling/typing problems, sorry...
Because they are required to diagnose the conversion and free to diagnose
the missing prototype

Actually, most of the compilers I was thinking about were pre-ANSI, so
they weren't required to do anything. It's probably the other way
around: Because most compilers already warned about int<->pointer
conversions the ANSI committee made that warning mandatory and because
most compilers did not warn about implicitely declared functions and a
lot of existing code relied on that they had to allow that.

As an aside, GCC still isn't able to warn about a missing prototype.
Today this isn't much of a problem since old-style declarations have
gone out of fashion, but when system header files still contained lots
of them, there was no sane combination of warning flags:

* -Wimplicit only warned if there was no declaration of malloc at
all. If the declaration was "void *malloc()", it wouldn't warn
about "p = malloc(10)", even though int and size_t might be of
different sizes.

* -Wstrict-prototypes was unusable: It would produce hundreds of
warnings for the system header files.

* -Wmissing-prototypes does something completely different.

Back to the topic: The standard doesn't require any specific form of a
diagnostic. A compiler which always prints "Warning: This program may
contain constraint violations" would be conforming, but of appallingly
bad quality. So for this discussion, I think it is completely irrelevant
whether something is a constraint violation or not. What is relevant is
whether real, existing, and widely used compilers issue useful warnings.

hp
 
?

=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F

What's good about it?

If you would like a helper function such as:

static inline int *alloc_int(void) {
return malloc(sizeof(int));
}

but are implementing it as a macro:

#define alloc_int() malloc(sizeof(int))

not casting the result means you can assign it to a float * without any
diagnostic. I will admit that this is not a very common case though.
 
K

Karl Heinze

On Sun, 16 Sep 2007 12:29:17 +0200, "Peter J. Holzer"

Concerning...
... whether real, existing, and widely used compilers
issue useful warnings.

Consider:

#include <stdio.h>

int main(void)
{
char *p = (char *) malloc(10);

return 0;
}

lcc-win32: "Missing prototype for 'malloc'.
Pelles C : "Missing prototype for 'malloc'".
gcc : "implicit declaration of function 'malloc'".


So at least the compilers *I* use issue useful warnings.


K. H.
 
?

=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F

And it is execreble dangerous coding in C.

Nonsense. In the cases where the code is broken with the cast, it's also
broken without the cast, and the argument about hiding a missing
inclusion of <stdlib.h> only applies if the programmer uses a compiler
that won't warn on implicit function declarations. Mine does, so how
would it be dangerous for me to cast the result of malloc?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top