<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On May 16, 2018, at 10:51 PM, Hubert Tong <<a href="mailto:hubert.reinterpretcast@gmail.com" class="">hubert.reinterpretcast@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); 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; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="gmail_extra"><div class="gmail_quote">On Thu, May 17, 2018 at 1:36 AM, JF Bastien<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:jfbastien@apple.com" target="_blank" class="">jfbastien@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word; line-break: after-white-space;" class=""><br class=""><div class=""><div class=""><div class="h5"><blockquote type="cite" class=""><div class="">On May 16, 2018, at 10:15 PM, Hubert Tong via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="m_-3301285794651543777Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Fri, May 11, 2018 at 7:26 PM, Shoaib Meenai via cfe-dev<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div lang="EN-US" class=""><div class="m_-3301285794651543777gmail-m_-9064138958871621122WordSection1"><span style="font-size: 11pt;" class="">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 class=""><div class="">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 class=""><span style="font-family: monospace, monospace;" class="">#include <stdarg.h><br class="">void abort(void);<br class="">int strcmp(const char *, const char *);<br class=""><br class="">typedef int Type;<br class="">typedef long NType;<br class=""><br class="">int myvscanf(const char *const fmt, va_list ap) {<br class=""> <span class="Apple-converted-space"> </span>if (strcmp(fmt, "%ld") != 0) { return 0; }<br class=""><br class=""> <span class="Apple-converted-space"> </span>NType *const p = va_arg(ap, NType *);<br class=""> <span class="Apple-converted-space"> </span>*p = 42;<br class=""> <span class="Apple-converted-space"> </span>return 1;<br class="">}<br class=""><br class="">__attribute__((__format__(__<wbr class="">scanf__, 2, 3)))<br class="">__attribute__((__noinline__, __noclone__))<br class="">void updateStatusFromPipe(Type *statusp, const char *const fmt, ...) {<br class=""> <span class="Apple-converted-space"> </span>va_list ap;<br class=""> <span class="Apple-converted-space"> </span>va_start(ap, fmt);<br class=""> <span class="Apple-converted-space"> </span>int ret = 0;<br class=""> <span class="Apple-converted-space"> </span>if (*statusp == 0) {<br class=""> <span class="Apple-converted-space"> </span>ret = myvscanf(fmt, ap);<br class=""> <span class="Apple-converted-space"> </span>}<br class=""> <span class="Apple-converted-space"> </span>va_end(ap);<br class=""> <span class="Apple-converted-space"> </span>if (ret >= 1 && *statusp != 0) abort();<br class="">}<br class=""><br class="">int main(void) {<br class=""> <span class="Apple-converted-space"> </span>Type status = 0;<br class=""> <span class="Apple-converted-space"> </span>updateStatusFromPipe(&status, "%ld", &status);<br class="">}</span><span class="Apple-converted-space"> </span><br class=""></div><div class=""><br class=""></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 class=""><br class=""></div><div class="">TL;DR: Please don't change the default.<br class=""></div></div></div></div></div></blockquote><div class=""><br class=""></div></div></div><div class="">The default has changed recently. We’re making the case that parts should be relegated to their own flag.</div><div class=""><br class=""></div><div class="">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 class="">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 class=""></div><div>I suspect that reading <a href="https://reviews.llvm.org/D42933" class="">https://reviews.llvm.org/D42933</a> would help understand the current proposal. If not, I’d like to understand which part of D42933 you don’t agree with. Specifically, is it about platform guarantees, portability warnings, printf specifically versus other format-like warnings, etc?</div><div><br class=""></div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); 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; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word; line-break: after-white-space;" class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">______________________________<wbr class="">_________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/cfe-dev</a></div></blockquote></span></div></div></blockquote></div></div></div></div></blockquote></div><br class=""></body></html>