[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-gnulib] Re: avoid using casts whenever possible [Re: gnulib/lib err
[Bug-gnulib] Re: avoid using casts whenever possible [Re: gnulib/lib error.c
Mon, 29 Sep 2003 13:00:29 +0200
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...
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,