Gabriel Dos Reis <[EMAIL PROTECTED]> 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
