Compiling GCC with g++: a report

[Zack Weinberg]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

[dropping most of the message - if I haven't responded, assume I don't
agree but I also don't care enough to continue the argument.  Also,
rearranging paragraphs a bit so as not to have to repeat myself]

> with the explicit call to malloc + explicit specification of sizeof,
> I've found a number of wrong codes -- while replacing the existing
> xmalloc/xcallo with XNEWVEC and friends (see previous patches and
> messages) in libiberty, not counting the happy confusion about
> xcalloc() in the current GCC codes.  Those are bugs we do not have
> with the XNEWVEC and friends.  Not only, we do get readable code, we
> also get right codes.
...
> I don't think so.  These patches make it possible to compile the
> source code with a C++ compiler.  We gain better checking by doing
> that. 

Have you found any places where the bugs you found could have resulted
in user-visible incorrect behavior (of any kind)?

If you have, I will drop all of my objections.

> If converting GCC to C++ is your ultimate goal, then I don't think
> you should block these patches.  They do not introduce C++, but also
> they do provide a path to local experiments before we ever have any
> huge fight about that.

To be clear, my ultimate goal is neither to introduce C++ nor to block
it.  My goal is to make sure that *if* a transition to C++ happens, it
happens with great care and attention to detail.  Part of this is not
doing anything that makes it seem easier to convert to C++ than it
actually is.  See my earlier response to Mark.

Now, if there's a benefit to your patches other than making that
hypothetical transition easier - like finding actual user-visible bugs -
then I don't have a problem with them.

> | This isn't an answer to the question I asked.  I asked for a more C++
> | friendly way to code *black box* use of enums, where (in C) one is
> | deliberately relying on the unchecked conversion to and from integral
> | types.
>
> The point was that an enum by itself is a black box.  There is no
> foward declaration of enums.  There is no need here for an abstraction
> for an abstraction.

So you don't see any value whatsoever to having (for instance) the
individual constants of 'enum machine_mode' be inaccessible in most of
GCC?  'cos I sure do.

zw