<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, May 17, 2018 at 12:12 PM, JF Bastien <span dir="ltr"><<a href="mailto:jfbastien@apple.com" target="_blank">jfbastien@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><span class="gmail-"><blockquote type="cite"><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div class="gmail_extra"><div class="gmail_quote"><div>Something Darwin-specific was considered to begin with in D42933; however, the discussion has evolved, and the version being proposed in this thread applies past the default that "recently changed". I am responding to this proposal, not D42933 (which, at this point, is more a discussion than a proposal).</div></div></div></div></blockquote></span><br><span class="gmail-"></span><div><span class="gmail-"><div><br></div></span><div>Sure. The reason I bring back D42933 is, as I’ve stated to Hans above, that if this proposal doesn’t address D42933 then we still need to address D42933. Further, D42933 is relevant because it’s a fairly similar datapoint to Facebook’s, albeit much more narrow.</div></div></div></blockquote><div>I agree, if the outcome of this proposal doesn’t address D42933, then the latter needs to be addressed separately.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><span class="gmail-"><div><br></div><br><blockquote type="cite"><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div>Specifically, is it about platform guarantees,<br></div></div></div></blockquote><div>I understand that platforms may provide guarantees, and that software may be written with those platforms in mind. Clang might not be limited to platforms with certain specific guarantees, and so, I think that adjusting for platform guarantees should be opt-in (by the target or otherwise).<br></div></div></div></div></blockquote><div><br></div></span><div>Opt-in by the platform was the original D42933 proposal. It sounds like you’re OK with that approach if Shoaib’s proposal goes in another direction?</div></div></div></blockquote><div>Yes; I am okay with that general direction.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><span class="gmail-"><div><br></div><br><blockquote type="cite"><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div class="gmail_extra"><div class="gmail_quote"><div>Furthermore, the extent of the specific guarantee being mentioned might be of interest. Is this a platform guarantee beyond having the same object representation, same value representation for all values, and the same alignment? A possible reading of the proposal with regards to conversion specifications for pointers to integral types would say that the proposal is talking about the type pointed to. Guarantees on the validity of using glvalues of one type to access objects of the other would then be of interest.<br><br>I agree that it is possible to read the proposal as not applying to pointer arguments. I am hoping we are good with clarifying on taking the latter interpretation.<br></div></div></div></div></blockquote><div><br></div></span><div>This is one of the reasons I dislike -Wformat-relaxed as a name. Relaxed what?</div></div></div></blockquote><div>Pinning down the name seems to be a step to take after determining what we need an option for.<br></div></div></div></div>