On 6/19/2014 5:55 PM, Botond Ballo wrote:
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?
No. What I'm saying is that an implicit goal of this paper is to help
gcc changes its non-conforming std::string. And them I'm saying that the
proposal doesn't actually solve that goal: gcc can't change the ABI
because it would break existing programs and code, and adding a new
explicitly-ABI-compatible interface won't work because existing programs
won't use it yet.
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
There are two points I wanted to make:
1. Mandating that you need to publish something doesn't mean it will
actually get published. C++ requires that compilers publish the
implementation-defined behavior decisions they make. I don't see any
documents for that for MSVC [which only has C] or Clang.
2. A published specification isn't necessarily sufficient for
interoperability. For example, in the OOXML specification, there's an
attribute whose full documentation is basically "emulate the behavior of
MS Word 95 on this text layout matter," without any description of what
that behavior actually is.
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.
See above.
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
My point is that it's not necessarily the lack of official ABIs that
block interoperability.
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
Sadly, no. I'm not sure such a thing can even exist.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
