Re: Compiling GCC with g++: a report

[Zack Weinberg <zack at codesourcery dot com>]

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

[...]
> The cast you're talking about is buried deep in XNEWVEC, XRESIZEVEC
> and such.  It is not anything you'll find in the code directly.  So,
> in fact we do not lose readability as you claim.

To be honest, I think XNEW* are less readable than bare xmalloc, and I
regret that I ever invented them.

> The patches of aligning us to the common subsets of C90 and C++ is
> following the consensus we developed as our coding standards.

I don't see that there is any such consensus.  I certainly consider
coding to the intersection of C90 and C++ acceptable only as a
stepping stone to coding in C++.  If we aren't going to do that, and
in short order, we have sacrificed the additional expressiveness of
C-that-is-not-C++ for no gain.

I was unclear in my previous message: it seems that you have found a
number of things, by your experiment, that are not just code outside
the intersection, but outright bugs.  The bugs should of course be
fixed.  Things that I consider outright bugs include: functions being
called with prototypes in scope that don't match their definitions;
use of numeric constants in interfaces when enumeration constants are
defined for those interfaces; 'typedef struct foo *foo'.

Things I consider correct coding, but outside the intersection of C90
and C++, include: not casting the return value of allocator functions;
not casting to void* when passing an arbitrary pointer to a function
that takes a void* parameter; unrestricted use of C++ keywords;
declaring structure fields with the same name as a structure tag in
scope.

> | I want to see more use of this idiom, not less; for
> | example, 'enum machine_mode' ought to be a black box to almost the
> | entire compiler. 
>
> Me too, but the way to make it a black box is not to cast it so
> unsigned int back forth willy nilly -- that does not make it a black
> box, on the contrary.  For example, we should be using EXPAND_NORMAL
> instead of plain "0".
>
> | I'd be delighted to hear of a more C++-friendly way to
> | code this. 
>
> See above.

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.

> I'm talking of the various gt_* objects created by the gengtype.
> Please, do have a look at the actual contents of the file and
> re-read what I wrote.

I haven't time; please post a reduced example and explain why my
suggestion won't work.

zw