On Sat, Sep 02, 2017 at 08:18:00AM +0000, Daniel Shahaf wrote:
> [replying to multiple]
> James McCoy wrote on Fri, Sep 01, 2017 at 08:15:05 -0400:
> > On Fri, Sep 01, 2017 at 03:07:16AM +0000, Daniel Shahaf wrote:
> > > I'm not sure I'm getting through here.
> > >
> > > The note does say "Don't allocate one of these yourself" but in the
> > > second sentence implies that the reason for this is that if you allocate
> > > it yourself and don't initialize all pointer-to-function members,
> > > Trouble will ensue. Therefore, the note could be construed as meaning
> > > that it is okay to allocate one of these yourself if you take care to
> > > initialize all pointer members.
> > The fact that a user can choose not to use the recommended API doesn't
> > mean that there is an ABI break. A user can already choose to allocate
> > the structure themselves and not initialize everything. Adding an item
> > to the struct doesn't change that.
> I'm afraid I don't follow. If a user allocates the struct themselves
> and doesn't initialize all members, then (1) they are in violation of
> the API's precondition, (2) their code will (depending on the repository
> data) dereference an uninitialized pointer-to-function at runtime.
> That's undefined behaviour de jure and some form of crash de facto.
Right, but it's not an ABI break. It's misuing the API.
> > I ran abi-compliance-checker against the head of branches/1.9.x and
> > trunk. It shows no incompatibility issues. The report is attached for
> > anyone that wants to view it.
> > : http://ispras.linuxbase.org/index.php/ABI_compliance_checker
> Thanks for adding this datapoint, but, how does it support your
> argument? The checker's output confirms what we already knew without
> it: that adding a member to a struct type can result in breakage when
> code compiled against 1.9 is run against 1.10 without rebuilding:
It confirms that there's not an ABI break. Code that's misuing the API
can break, yes, but not code that's using the API correctly.
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Received on 2017-09-02 13:15:07 CEST