<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jul 31, 2014 at 9:49 AM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hold on, I'm still not sure what kind of guarantees (restrictions) the C<br>
API imposes.<br>
<br>
If I implement (2), then -verify will fail if someone (e.g.) adds<br>
`@llvm.global_ctors` with 2 fields.  Does C API stability preclude<br>
making that change?<br></blockquote><div><br></div><div>Now you have reached the crux of it. Nobody really agrees. The verifier doesn't reject the 2-field form yet, because I thought that would be a C API break.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Assuming it does, are there serious concerns with me implementing (1)<br>
instead?<br></blockquote><div><br></div><div>That was my original intention: this would be an optional field indefinitely, but it means globalopt, asan, and other consumers of global_ctors have to dispatch on the size of the struct forever.</div>
</div></div></div>