Zack Weinberg wrote:
Um, yeah. I completely botched that explanation. My apologies. I'm
concerned about four different scenarios which may arise when the
preexisting C++ compiler and runtime are ABI-incompatible with the C++
compiler and runtime being built; none are source compatibility
issues, as you point out, however two of them have just the same
effect from the user's point of view: imposing constraints on what
compiler can be used to build the compiler.
I agree that these are valid concerns.
Certainly, I can imagine us (CodeSourcery) considering shipping
statically linked binaries for quite some time in order to avoid
problems for customers, even though that would be less efficient.
Like you, I do think these problems are surmountable; but, also like
you, I think it would take some time to get all the problems solved. I
don't really think, though, that this is immediately relevant; Gaby's
trying to fix things that seem to me like they will actually make for
better C code, and, right now at least, going to C++ isn't on the table.
I think you agree that most of the changes Gaby wants to make are for
the better (with the possible exception of casting the return value of
malloc, which will be hidden in a macro that's probably less error-prone
that writing out the malloc calls directly) -- but you're concerned
about the fact that doing this work now might make it too easy for us to
switch to C++ without thinking about all the issues?
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
