<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, May 17, 2018 at 1:56 AM, 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;"><br><div><div><div class="gmail-h5"><br><blockquote type="cite"><div>On May 16, 2018, at 10:51 PM, Hubert Tong <<a href="mailto:hubert.reinterpretcast@gmail.com" target="_blank">hubert.reinterpretcast@gmail.<wbr>com</a>> wrote:</div><br class="gmail-m_2744984163904927337Apple-interchange-newline"><div><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">On Thu, May 17, 2018 at 1:36 AM, JF Bastien<span class="gmail-m_2744984163904927337Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:jfbastien@apple.com" target="_blank">jfbastien@apple.com</a>></span><span class="gmail-m_2744984163904927337Apple-converted-space"> </span><wbr>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;"><br><div><div><div class="gmail-m_2744984163904927337h5"><blockquote type="cite"><div>On May 16, 2018, at 10:15 PM, Hubert Tong via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="gmail-m_2744984163904927337m_-3301285794651543777Apple-interchange-newline"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, May 11, 2018 at 7:26 PM, Shoaib Meenai via cfe-dev<span class="gmail-m_2744984163904927337Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.<wbr>org</a>></span><span class="gmail-m_2744984163904927337Apple-converted-space"> </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 lang="EN-US"><div class="gmail-m_2744984163904927337m_-3301285794651543777gmail-m_-9064138958871621122WordSection1"><span style="font-size:11pt">Of course, we should also ensure that the optimizer doesn't do anything surprising when there's a type mismatch between the specifier and the argument but both types have the same size and alignment (i.e., the case where the relaxed format warning won't fire), both now and in the future.</span></div></div></blockquote><div><div>The "contract" for the format string and the corresponding argument is as described elsewhere in the thread, and it is rather more interesting for scanf than not. GCC's implementation technology is apparently able to optimize (at -O2 and up, at least when targeting powerpc64le-linux-gnu) the check feeding the abort() in the following to not observe the write performed in the ersatz scanf():<br><span style="font-family:monospace,monospace">#include <stdarg.h><br>void abort(void);<br>int strcmp(const char *, const char *);<br><br>typedef int Type;<br>typedef long NType;<br><br>int myvscanf(const char *const fmt, va_list ap) {<br> <span class="gmail-m_2744984163904927337Apple-converted-space"> </span>if (strcmp(fmt, "%ld") != 0) { return 0; }<br><br> <span class="gmail-m_2744984163904927337Apple-converted-space"> </span>NType *const p = va_arg(ap, NType *);<br> <span class="gmail-m_2744984163904927337Apple-converted-space"> </span>*p = 42;<br> <span class="gmail-m_2744984163904927337Apple-converted-space"> </span>return 1;<br>}<br><br>__attribute__((__format__(__sc<wbr>anf__, 2, 3)))<br>__attribute__((__noinline__, __noclone__))<br>void updateStatusFromPipe(Type *statusp, const char *const fmt, ...) {<br> <span class="gmail-m_2744984163904927337Apple-converted-space"> </span>va_list ap;<br> <span class="gmail-m_2744984163904927337Apple-converted-space"> </span>va_start(ap, fmt);<br> <span class="gmail-m_2744984163904927337Apple-converted-space"> </span>int ret = 0;<br> <span class="gmail-m_2744984163904927337Apple-converted-space"> </span>if (*statusp == 0) {<br>   <span class="gmail-m_2744984163904927337Apple-converted-space"> </span>ret = myvscanf(fmt, ap);<br> <span class="gmail-m_2744984163904927337Apple-converted-space"> </span>}<br> <span class="gmail-m_2744984163904927337Apple-converted-space"> </span>va_end(ap);<br> <span class="gmail-m_2744984163904927337Apple-converted-space"> </span>if (ret >= 1 && *statusp != 0) abort();<br>}<br><br>int main(void) {<br> <span class="gmail-m_2744984163904927337Apple-converted-space"> </span>Type status = 0;<br> <span class="gmail-m_2744984163904927337Apple-converted-space"> </span>updateStatusFromPipe(&<wbr>status, "%ld", &status);<br>}</span><span class="gmail-m_2744984163904927337Apple-converted-space"> </span><br></div><div><br></div>The "now or in the future" sounds like needing to do "worse" or "better" than what GCC is doing to avoid "anything surprising", because "on par" with GCC fits the bill for something "surprising". Which is to say that, in my opinion, there is no avoiding "something surprising" "in the future" on code that the proposed relaxation is letting slip through.<br><br></div><div>TL;DR: Please don't change the default.<br></div></div></div></div></div></blockquote><div><br></div></div></div><div>The default has changed recently. We’re making the case that parts should be relegated to their own flag.</div><div><br></div><div>Your argument ignores the prerogative that platforms have in providing additional guarantees. NSInteger has that guarantee on Darwin platforms, it should be honored. I further don’t see how optimizing printf as you seem to suggest could be possible is ever useful or desirable.</div></div></div></blockquote><div>Why is changing the behaviour for "everyone" for possible guarantees on some platforms the approach as opposed to adjusting the warning based on the guarantees that the target to known to provide?</div></div></div></div></div></blockquote><div><br></div></div></div><div>I suspect that reading <a href="https://reviews.llvm.org/D42933" target="_blank">https://reviews.llvm.org/<wbr>D42933</a> would help understand the current proposal.</div></div></div></blockquote><div>Okay, I needed the context in terms of how the proposal evolved. Thanks.<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><div>If not, I’d like to understand which part of D42933 you don’t agree with.<br></div></div></div></blockquote><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).<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><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><br>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><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><div>portability warnings,<br></div></div></div></blockquote><div>The proposed change goes beyond nixing portability checking. It is a shift in a contract between the caller providing a format string, and a callee processing a format string. It
 assumes specific details about how variable arguments work in the 
calling convention, how the attendant macros are implemented, and 
limitations in optimizer technology. It may be weird, but not 
prohibited, for types that cannot be differentiated when in memory to 
have different treatment in the registers used to pass them.<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><div>printf specifically versus other format-like warnings, etc?</div></div></div></blockquote><div>I think the major use case for the proposal is covered by limiting the 
scope to changing the checking of arguments of integral type to the 
"system-provided" printf family of functions.<br><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><div><br></div><blockquote type="cite"><div><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 style="overflow-wrap: break-word;"><div><span><blockquote type="cite"><div>______________________________<wbr>_________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a></div></blockquote></span></div></div></blockquote></div></div></div></div></blockquote></span></div><br></div></blockquote></div><br></div></div>