Re: Cast abuse



On Tue, 20 November 09:58 Matthias Andree wrote:
> On Mon, 19 Nov 2001, Brian Stafford wrote:
> 
> > <rant>
> > As a general point, I feel that when programming in C, if a cast is used,
> > something is wrong in the code.  All reasonable efforts should be made to
> > rewrite the code avoiding the cast.  Use casts only as a last resort, after
> 
> > all a cast silences the compiler about potential coding errors.  Also
> > remember that void pointers eliminate the need for a lot of casts, e.g.
> code
> > like "ptr = (int *) malloc(..." is always unnecessary since malloc returns
> a
> > void *.  Just write "ptr = malloc(...".  The same goes for comparisons with
> 
> > void pointers, forget the cast.
> > </rant>
> 
> Well, you will HAVE TO use casts away from void * in C++,

I couldn't care less about what has to be done in C++.  I'm talking about C.  
Last time I looked C and C++ were different languages.

> and it's
> pretty reasonable to do that in C as well.

I disagree.  A cast overrides the compiler's assumptions.  That may disable 
warnings about incorrect code.  Human programmers always make mistakes.  We 
humans need all the help the compiler can offer.

> You CANNOT avoid casts for
> socket functions either

What is your point?  There are times when casts are necessary; that's why they 
are provided.  I'm arguing against their use when they are not necessary.  I 
foolishly thought this was a reasonable point of view.

> (didn't look at your patch).

You are challenging my views but you can't be bothered to look at the patch.  
I find that insulting.

> If you're after
> type-safe programming, go for Ada95 or even stricter languages.

No argument there.  But that doesn't excuse sloppiness in C programming, the 
"I'm not sure about this so I'll stick in a cast" approach.  Code without 
casts looks better and is usually easier to understand, especially by someone 
other than the original author.

> Note, GCC has some warnings about cast abuse you can turn on.

Yep and its worth turning them on too.

--
BCS



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]