[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnulib] Re: avoid using casts whenever possible [Re: gnulib/lib
From: |
Bruno Haible |
Subject: |
Re: [Bug-gnulib] Re: avoid using casts whenever possible [Re: gnulib/lib error.c |
Date: |
Tue, 30 Sep 2003 12:51:58 +0200 |
User-agent: |
KMail/1.5 |
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