<div dir="ltr">This is a convincing point, but the reasoning here is somewhat different, since it's dealing with pointer-types, and then an actual pointer-dereference of the incorrect type. That's certainly a bad idea -- I agree it'd be quite unwise to change the behavior when dealing with pointers, either in the scanf specifiers or for the expected pointee-type of %n in printf.<div><br></div><div>I think the question at hand is whether a type-mismatch of the value itself is a problem you should be worried about. E.g., calling "va_arg(long)" when passing a value of type int to the call, where int and long are "the same".<div><div><br></div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, May 17, 2018 at 1:16 AM Hubert Tong via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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 dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</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 lang="EN-US">
<div class="m_7825653118964040830gmail-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>  if (strcmp(fmt, "%ld") != 0) { return 0; }<br><br>  NType *const p = va_arg(ap, NType *);<br>  *p = 42;<br>  return 1;<br>}<br><br>__attribute__((__format__(__scanf__, 2, 3)))<br>__attribute__((__noinline__, __noclone__))<br>void updateStatusFromPipe(Type *statusp, const char *const fmt, ...) {<br>  va_list ap;<br>  va_start(ap, fmt);<br>  int ret = 0;<br>  if (*statusp == 0) {<br>    ret = myvscanf(fmt, ap);<br>  }<br>  va_end(ap);<br>  if (ret >= 1 && *statusp != 0) abort();<br>}<br><br>int main(void) {<br>  Type status = 0;<br>  updateStatusFromPipe(&status, "%ld", &status);<br>}</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>
_______________________________________________<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" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>