[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,


reply via email to

[Prev in Thread] Current Thread [Next in Thread]