Re: [Bug-gnulib] Re: avoid using casts whenever possible [Re: gnulib/lib error.c

[Bruno Haible]

Paul Eggert wrote:
> I assume you mean the following rewrite:
>
>        char *p = xmalloc (strlen (s) + 1);
>        return strcpy (p, s);
> ->
>        return strcpy (xmalloc (strlen (s) + 1), s);
>
> But this rewrite results in valid C code; it shouldn't produce a
> warning, any more than the original code did.  (Hmm, perhaps you're
> referring to a C++ warning?  Then please see below.)

Yes this is what I meant. You're right, gcc gives no warning for the
latter code either. One more reason to prefer XMALLOC with the type
cast over plain xmalloc...

> > 2) Suddenly the need can arise to use a C++ compiler for C code
>
> That would be a reasonable practical motivation, if it happens that
> C++ compilers are used often to compile GNU applications, and we want
> to cater to such compilers to encourage the spread of free software.
> But I'm a bit dubious about making C++ compatibility a goal for all
> gnulib code.  I don't think it's too much these days to ask people to
> use C compilers, or at least to use C++ compilers that compile
> standard C89 constructs as extensions.  So I don't see C++
> compatibility as being a significant help to promoting the use of
> gnulib code.

For the .c parts of gnulib, I agree. But the .h header files need to
be usable from within C++, otherwise things like Windows DLLs become
much harder to use.

> The compiler will catch some type errors but it won't catch all of
> them, because in C casts are usually a stronger mechanism than what is
> needed.  For example, if I mistakenly think a pointer N is an integer,
> and cast N to size_t by mistake, the compiler won't complain (on the
> vast majority of platforms, anyway); but if I instead assign N to a
> size_t variable without a cast, the compiler will diagnose the error.

Yes, and this is an argument in favour of changing

           (foo_t *) xmalloc (...)

into
           XMALLOC (foo_t, ...)

because in the latter case there are fewer hand-maintained type casts.

> > One uses the XMALLOC macro in the form it was before Paul's
> > 2003-07-22 patch.
>
> (Just for the record: I installed that patch, but it was Jim's idea.  :-)

Still I'd like to ask for reversal of that patch, for the reasons cited
above: improved compile-time type checking.

> I don't like XMALLOC (either the
> old or the new form), because it is a function-style macro but it does
> not behave like a function.  I think we should get rid of it, even if
> we lose a bit of compile-time type-checking thereby.  (And I don't say
> this lightly: I'm a big fan of compile-time checking.)

I'm not using XMALLOC myself either, currently, because I believe that
even with hand-written casts I don't make terrible mistakes. But it is
Jim's and your argument that as few hand-maintained casts as possible
is best, to reduce the opportunities for wrong casts; and therefore my
plea to keep this macro in its useful form.

Bruno