<div dir="ltr">It's not very clear to me if this patch is stamped. Rafael, are you ok with this patch?</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 16, 2013 at 3:28 PM, Michael Spencer <span dir="ltr"><<a href="mailto:bigcheesegs@gmail.com" target="_blank">bigcheesegs@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="h5"><div class="gmail_extra"><div>On Tue, Jul 16, 2013 at 2:52 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br>

</div><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Actually this code is outside of lld and was written mainly by Michael. I'd like to get his input about API rework. If he's okay with API rework I'm fine to work on that. However, what I'm trying to do is to add a relatively small method to the set of methods which spans multiple files in a consistent manner, so I'm tempted to say API rework shouldn't block this change.</div>


<div><div>

<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 16, 2013 at 2:41 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br>




<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><div><br><div class="gmail_quote">


On Tue, Jul 16, 2013 at 2:37 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>> I agree with you in general but in this case consistency looks more<br>



> important than that. Look at the other methods, such as the above two.<br>
> getCOFFHeader() and getPE32Header() will never fail and will always return<br>
> object_error::success. Other methods in the other files in the same<br>
> directory are written in the similar manner. If we change the signature of<br>
> this function, it won't fix the API, but it'd make the API cluttered.<br>
><br>
> I'd think we should change all the other methods in the directory not to<br>
> return error_code, if we think it's the right thing to do. That should be<br>
> done in another patch.<br>
<br>
</div>I think we should change it all, yes. If you don't want to have the<br>
methods temporarily in a mixed state, then please change the existing<br>
ones first.</blockquote></div><br></div></div>Rafael, I don't think that's necessary. This is all code that Rui has written and been maintaining. If he would prefer to do the API rework in a follow-up patch that seems totally fine.</div>





</div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div><div class="gmail_extra">Error handling can be fixed separately. It's a problem in all of libObject.</div><div class="gmail_extra"><br></div><div class="gmail_extra">

lgtm.</div><span class="HOEnZb"><font color="#888888">
<div class="gmail_extra"><br></div><div class="gmail_extra">- Michael Spencer<br></div><div class="gmail_extra"><br></div></font></span></div>
</blockquote></div><br></div>