Re: C/C++ guidelines

On 2007-09-16 21:46, Mark McIntyre <markmcintyre@xxxxxxxxxxx> wrote:
On Sun, 16 Sep 2007 12:00:21 +0200, in comp.lang.c , Karl Heinze
<nomail@invalid> wrote:
On Sat, 15 Sep 2007 22:45:00 -0400, CBFalconer <cbfalconer@xxxxxxxxx>
wrote:
[...] 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>.

Splitting hairs. If the cast were not there, you'd be warned about the
missing prototype.

No, you'd be warned about a conversion from integer to pointer.

By inserting the cast, you mask the other error.

Maybe, maybe not. If the compiler warned about a missing prototype, it
would do so with or without the cast.


On the other hand most modern C compilers (as it seems) would catch
that lapse (and produce a warning).

Its a warning and (in C89 at least) no diagnosis is actually required.
So you're relying on Quality of Implementation.

If you rely on getting a useful diagnostic for an implicit conversion
from int to a pointer, you are also relying on Quality of
Implementation. The standard only says that "a diagnostic" is required,
but doesn't require any useful information to be included in the
diagnostic. "Warning: This program may contain errors" is perfectly
acceptable as far as the standard is concerned.

You may have a point if you claim that almost all compilers do warn
about the implicit conversion while only a few warn about the implicit
declaration, but you would have to back up this claim with facts.

As a tiny counter example, I submit that gcc 4.1.2 without any -W*
options warns:

foo.c:3: warning: incompatible implicit declaration of built-in function
‘malloc’

both with and without the cast. It doesn't warn about the implicit
conversion in this case (but it does if I replace "malloc" with "foo").

hp


--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp@xxxxxx |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
.

Relevant Pages

  • Re: 0/1 Knapsack problem, what am I doing wrong
    ... malloc is the right thing to do in C. ... *not* cast malloc. ... potentially unsafe conversion. ... there is no diagnosis for those places, ...
    (comp.lang.c)
  • Re: new vs override - a practical example
    ... interpret it as without using the cast operator -- which is the issue here. ... * From any class-type S to any class-type T, provided S is derived from T. ... * From any class-type S to any interface-type T, ... Implicit conversion is exactly implicit. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Why is this invalid
    ... is no implicit conversion between 'Test.IDerived1' and 'Test.IDerived2' ... Jon's solution is the correct one, although you don't need to cast ... them both (assuming that IBase is the base interface for both ... IDerived1 and IDerived2). ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: writing library functions and pointers?
    ... But whatever you do, LOSE THE CAST. ... What it means is that you can write some unsafe conversions in C, ... but there is no /required/ diagnosis for them. ... a proper declaration for malloc (usually by forgetting to include ...
    (comp.lang.c)
  • Re: Terminology : casting/conversion
    ... It is certainly more consistent ... to use the phrase "implicit conversion". ... standard defines "cast" as, in effect, "the syntactic construct ... Note that the same sequence of six "int" constants might be used ...
    (comp.lang.c)