----- Original Message ----- > From: "Joshua Cranmer 🐧" <pidgeo...@gmail.com> > > Perhaps a bit late to be saying this, but after reading this paper, I've > come to object to it.
Appreciate the feedback. I have some clarification questions to help me understand your objections better. > It explicitly mentions the issue that gcc can't make std::string > conforming to C++11 because doing so would require breaking ABI > compatibility, and it opines that making this move would allow gcc to > break the compatibility. This is a complete fallacy: breaking binary > compatibility is as much about the informal compatibility guarantees as > the formal ones. In Mozilla code, we explicitly stopped all binary > compatibility guarantees in Gecko 4 (early 2011). Even then, we decided > to make nsILocalFile an empty interface "for a little while" to avoid > breaking extensions... and 2 years, 2 months, 10 days later, we still > have 486 uses of this interface in mozilla-central alone. Our plans to > kill off XPIDL interfaces for the now-WebIDL-based DOM don't even extend > to nsIDOMElement and friends specifically for compatibility reasons. > Looking at the factors that block gcc's use of a conforming std::string, > this approach wouldn't expedite it at all. Are you saying that gcc - assuming that for some platforms, it is considered the platform vendor, and therefore the provider of std::abi - would likely ship their non-conforming std::string as std::abi::string in order to maintain ABI compatibility between the two? > Publishing official ABIs is rather meaningless: note that some details > of the Win64 C ABI are not officially published and had to be reverse > engineered (I think). Not sure what the point here is. If the ABI is published, people won't have to reverse engineer things. That's surely an improvement. > It's also worth noting that MSVC's C++ ABI does > not appear to have a formal design or internal documentation, judging by > the presence of clear bugs in name mangling. It even may not be stable: > a few name manglings require computing hashCode(something). This proposal, if accepted, would require Microsoft to create a stable ABI and document it publicly in order to be conforming. (This aspect of the proposal is viewed as a Good Thing even by people in the committee who have objections to other aspects of the proposal.) > What blocks > interoperability with Win32's exception handling isn't the lack of a > specification but rather the existence of a patent [which I believe > expires this year]. It is out of scope of the Standard to make requirements related to intellectual property. However, Herb said - and I believe - that it is in the spirit of the proposal that platform vendors do not place IP hurdles in front of third parties implementing their ABI. > The final--and biggest flaw--is that the envisioned mode of ABI > compatibility is to create a subset of the code that guarantees ABI > compatibility and make that subset grow steadily largely over time. I > don't think this works (witness the failure of the 8-bit MIME scheme in > this regard). extern "abi" can't be used by existing projects because it > doesn't exist yet; it can't be changed to in a future version if it > causes an ABI break because it breaks their compatibility. And if it > doesn't change ABI, then there's no point to it in the first place. New > projects can use it, but at moderate risk to compatibility with > pre-existing projects (depending on exact wording of specifications). > And so long as projects that don't use it exists, tools that want to do > FFI still need to worry about the "unstable" ABI. std::abi has the same > issues, with particularly stronger emphasis on the compatibility > mismatch between projects that use it and projects that don't. Do you have in mind a roadmap to an ABI that is portable across implementations on a given platform, that does not suffer from these issues? > So what we have, in short, is a paper that proposes an underdefined ABI > guarantee that, even were it fully defined, wouldn't be sufficient to be > usable by the people who most would want to use it. What do you mean by "underdefined"? Cheers, Botond _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
