<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 17, 2015 at 3:46 PM, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Aug 17, 2015 at 12:31 PM, James Y Knight via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> I'd propose that the only 100% strict rule should be that if the ABI/API<br>
> changes, it is done in a way that *loudly* breaks old programs -- e.g. they<br>
> fail to compile, link, or run (depending on how the other-lang wrappers are<br>
> accessing the API functions) -- not that you get some random weird<br>
> misbehavior because a function's argument types or return type has been<br>
> changed.<br>
<br>
<br>
</span>This would require a level of testing that we don't have, just to make<br>
sure that happens, no?<br></blockquote><div><br></div><div>Okay, kinda? I mean, more testing is always good. If you're missing a test, and then break something by accident, well, that sucks. But, the important first step is to agree that the *policy* is to not change the C API in that way. If something like that does happen, treat it as a bug to be (hopefully) fixed, rather than something that's allowed by the development policy so "oh well".</div><div><br></div><div>With the way the C API is currently defined, maintaining that property actually seems like it's pretty straightforward, because all the types it uses are defined in the C API headers. So, basically: be careful about how you change the C API headers. Which people already are being.</div><div><br></div><div>Maybe I shouldn't have said "100% strict" -- I didn't actually mean "the world will explode if we get this wrong and introduce a bug" -- it certainly won't. It would just be inconvenient, so have a policy of not doing it.</div><div><br></div></div></div></div>