[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-gnulib] Re: avoid using casts whenever possible [Re: gnulib/lib err
From: |
Bruno Haible |
Subject: |
[Bug-gnulib] Re: avoid using casts whenever possible [Re: gnulib/lib error.c |
Date: |
Mon, 29 Sep 2003 13:00:29 +0200 |
User-agent: |
KMail/1.5 |
Jim Meyering wrote:
> > I still find the code more maintainable with the cast than without.
> > But we have already been through this.
>
> Don't want to beat a dead horse, but...
> Why?
1) It allows to do the usual code reorganizations without thinking about
types. For example, the typical "replace variable that is only used
once with its initial value" reorganization
char *p = xmalloc (strlen (s));
return strcpy (p, s);
-->
return strcpy (xmalloc (strlen (s)));
produces a warning.
2) Suddenly the need can arise to use a C++ compiler for C code; this
happened twice to me recently:
- in GNU clisp, in order to use a GCsafety checker that relies
on the C++ "operator =" and "operator <resulttype>" hooks,
- in GNU gettext, in order to produce Windows DLLs with minimal
changes to the source code.
> IMHO, casts in C make code *less* maintainable because the type of
> the cast often must agree with that of a related variable, and there
> is no mechanism to ensure that they stay in sync.
Sure there is a mechanism: One uses the XMALLOC macro in the form it was
before Paul's 2003-07-22 patch. I.e. if I use the idiom
foo_t *variable = XMALLOC (N, sizeof (foo_t))
and someday I make a mistake, saying
bar_t *variable = XMALLOC (N, sizeof (foo_t))
gcc will give me a warning. This is precisely the automatic check (that
both types are in sync) that you are asking for,
Bruno