On Mon, May 23, 2005 at 09:01:20PM -0700, Zack Weinberg wrote: > As a general observation: A lot of the things you have found to be > problematic, are in fact preferred idioms for C code. For instance, > no standard-C programmer would ever write an explicit cast on malloc's > return value. I think that we are losing something, if only in > readability, if we restrict our code to the subset of C which is also > correct C++. Now, if we were migrating to C++, that would be okay, > because we would (eventually) get all of the additional expressive power > of C++ in exchange. However, if we're not migrating to C++, I'm opposed > to the inclusion of patches that restrict our C code to the subset which > is correct C++. Furthermore, as I've said before, I support migrating > to C++ -- but only if the C++ ABI and libstdc++ soname are first > permanently frozen. If we do not do that first, we risk being trapped > into a situation where we need specific versions of GCC to compile > specific newer versions of GCC, which would be a Bad Thing.
You keep saying this and I don't think it means what you think it means... Being stuck requiring a specific version of GCC to compile a specific newer version of GCC would be a restriction on _source compatibility_ and has nothing to do with binary compatibility. I don't see any way that the libstdc++ soname, for instance, could matter to this at all. If you do, then please be more precise about what problems you're talking about. > The C++ ABI seems to be stable at this point, but there is not yet > consensus that it will never again be changed. The libstdc++ team is > currently developing yet another new, incompatible version, so I see no > hope for a permanent freeze of its soname in the near future. Thus, > while you've discovered some interesting things by trying this, I don't > think C++ compatibility patches should be applied now. There is no such thing as an ABI that will never again be changed. Designing anything at all around that assumption is just asking to be hurt. -- Daniel Jacobowitz CodeSourcery, LLC
