<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><blockquote type="cite" class=""><div class="">On May 16, 2018, at 10:41 AM, Shoaib Meenai via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="WordSection1" style="page: WordSection1; 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;"><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">I don't think making NSInteger and size_t consistent at this point is an option, because of the ABI implications, but I'll leave that for the Apple folks to answer.</div></div></div></blockquote><div><br class=""></div><div>Correct.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="WordSection1" style="page: WordSection1; 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;"><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 11pt;" class="">The other thing to point out is, I'm dealing with codebases with *thousands* of such instances.</span></div></div></div></blockquote><div><br class=""></div><div>This is why we care about this as well.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="WordSection1" style="page: WordSection1; 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;"><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 11pt;" class="">We've cleaned up a lot of them (and the clang fix-its do come in handy here), but at some point you just hit a wall and decide to go with -Wno-error=format to be able to move forward. I'm trying to avoid throwing the baby out with the bathwater here by adding an option to still retain some of the format errors, at least. My plan is to actually go back and clean up the rest of the issues as well, but this would allow us to do it in a staged fashion instead of an all-or-nothing.</span></div></div></div></blockquote><blockquote type="cite" class=""><div class="WordSection1" style="page: WordSection1; 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;"><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="border-style: solid none none; border-top-width: 1pt; border-top-color: rgb(181, 196, 223); padding: 3pt 0in 0in;" class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><b class=""><span style="font-size: 12pt;" class="">From:<span class="Apple-converted-space"> </span></span></b><span style="font-size: 12pt;" class="">cfe-dev <<a href="mailto:cfe-dev-bounces@lists.llvm.org" class="">cfe-dev-bounces@lists.llvm.org</a>> on behalf of cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>><br class=""><b class="">Reply-To:<span class="Apple-converted-space"> </span></b>Nico Weber <<a href="mailto:thakis@chromium.org" class="">thakis@chromium.org</a>><br class=""><b class="">Date:<span class="Apple-converted-space"> </span></b>Wednesday, May 16, 2018 at 5:33 AM<br class=""><b class="">To:<span class="Apple-converted-space"> </span></b>Aaron Ballman <<a href="mailto:aaron@aaronballman.com" class="">aaron@aaronballman.com</a>><br class=""><b class="">Cc:<span class="Apple-converted-space"> </span></b>cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>><br class=""><b class="">Subject:<span class="Apple-converted-space"> </span></b>Re: [cfe-dev] Relaxing format specifier checks<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><a name="_MailOriginalBody" class="">Another +1 to that.<o:p class=""></o:p></a></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><br class="">For NSInteger, one thing that projects can do until the SDK either makes NSInteger and ssize_t consistent or offers format strings for NSInteger instead of recommending casting is to add something like this and use it:</span></div></div></div></div></blockquote><div><br class=""></div><div>That’s not a solution that should be recommended users go with, and it’s not something most users would go with. It therefore doesn’t fix the issue.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class="WordSection1" style="page: WordSection1; 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;"><div class=""><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">// The size of NSInteger and NSUInteger varies between 32-bit and 64-bit<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">// architectures and Apple does not provides standard format macros and<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">// recommends casting. This has many drawbacks, so instead define macros<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">// for formatting those types.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">#if defined(OS_MACOSX)<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">#if defined(ARCH_CPU_64_BITS)<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">#if !defined(PRIdNS)<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">#define PRIdNS "ld"<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">#endif<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">#if !defined(PRIuNS)<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">#define PRIuNS "lu"<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">#endif<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">#if !defined(PRIxNS)<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">#define PRIxNS "lx"<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">#endif<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">#else // defined(ARCH_CPU_64_BITS)<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">#if !defined(PRIdNS)<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">#define PRIdNS "d"<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">#endif<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">#if !defined(PRIuNS)<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">#define PRIuNS "u"<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">#endif<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">#if !defined(PRIxNS)<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">#define PRIxNS "x"<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">#endif<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">#endif<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">#endif // defined(OS_MACOSX)<o:p class=""></o:p></span></div></div></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">On Wed, May 16, 2018 at 7:49 AM, Aaron Ballman via cfe-dev <</span><a href="mailto:cfe-dev@lists.llvm.org" target="_blank" style="color: purple; text-decoration: underline;" class=""><span class="">cfe-dev@lists.llvm.org</span><span class=""></span></a><span class="">> wrote:<o:p class=""></o:p></span></div><blockquote style="border-style: none none none solid; border-left-width: 1pt; border-left-color: rgb(204, 204, 204); padding: 0in 0in 0in 6pt; margin-left: 4.8pt; margin-right: 0in;" class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">I'm in the same camp as Hans and Joerg -- I would prefer to keep the<br class="">existing check functionality and provide a more relaxed mode as an<br class="">alternative if one is necessary (for the same reasons they bring up).<br class=""><br class="">~Aaron<o:p class=""></o:p></span></div><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><br class="">On Wed, May 16, 2018 at 7:28 AM, Hans Wennborg via cfe-dev<br class=""><</span><a href="mailto:cfe-dev@lists.llvm.org" style="color: purple; text-decoration: underline;" class=""><span class="">cfe-dev@lists.llvm.org</span><span class=""></span></a><span class="">> wrote:<br class="">> Sorry for the late reply. I didn't see the thread until now.<br class="">><br class="">> On Sat, May 12, 2018 at 1:26 AM, Shoaib Meenai via cfe-dev<br class="">> <</span><a href="mailto:cfe-dev@lists.llvm.org" style="color: purple; text-decoration: underline;" class=""><span class="">cfe-dev@lists.llvm.org</span><span class=""></span></a><span class="">> wrote:<br class="">>> Hi all,<br class="">>><br class="">>><br class="">>><br class="">>> Currently, clang's format specifier check warnings (-Wformat) check for<br class="">>> exact type matches between the specifier and the corresponding argument. I'm<br class="">>> proposing adding an option to relax these warnings such that it doesn't warn<br class="">>> when there's a type mismatch but the types of the specifier and the argument<br class="">>> have the same size and alignment (and are both integral). For an example, on<br class="">>> an LLP64 system, attempting to print a long with "%d" would not warn, but<br class="">>> attempting to print a long long with "%d" would still warn. We could either<br class="">>> do this relaxation for -Wformat and add a new option for the stricter<br class="">>> warnings, or keep -Wformat as is and add a new option for the relaxed<br class="">>> warnings.<br class="">>><br class="">>><br class="">>><br class="">>> The motivation is that during the 6.0 timeframe, clang gained format<br class="">>> specifier checking for %zd (r308067) and %tu (r314470), which made -Wformat<br class="">>> fire in a lot of additional cases. A particularly common case is programs<br class="">>> using %zd to print NSInteger. This will be warning-free on 64-bit targets,<br class="">>> where both ssize_t and NSInteger are long, but warn on 32-bit targets, where<br class="">>> ssize_t is still long but NSInteger is int. This additional warning<br class="">>> motivated<span class="Apple-converted-space"> </span></span><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D42933&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=Dc2LUIK-XaYupO2Hkkb0rUQ1P7J1i_d1FWGuq9xVIPo&s=TLCnZBAN4H1MpoWz2cq-3bvr7rxnMWTy5MkbjxlzalA&e=" target="_blank" style="color: purple; text-decoration: underline;" class=""><span class="">https://reviews.llvm.org/D42933</span><span class=""></span></a><span class="">, which attempted to special case<br class="">>> %z and NSInteger; the diff's comments have a bunch of additional discussion<br class="">>> about this issue. The conclusion there was that, although having mismatched<br class="">>> specifiers of this nature is definitely technically incorrect, there<br class="">>> shouldn't actually be any issues in practice when the size and alignment of<br class="">>> the specifier and the argument match. Ideally people would update their<br class="">>> codebases to use proper specifiers, but that can be impractical for large<br class="">>> codebases, and it would be really nice to have a way to restrict the warning<br class="">>> to the cases which will actually cause problems in practice.<br class="">><br class="">> It sounds like the problem is really that NSInteger and size_t are<br class="">> typedeffed to different types on 32-bit. Would it be possible to get<br class="">> that fixed instead?<br class=""></span></div></div></div></blockquote></div></div></div></blockquote><div><br class=""></div><div>NSInteger is, on purpose, the same size as a size_t. The types can’t change.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class="WordSection1" style="page: WordSection1; 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;"><div class=""><div class=""><blockquote style="border-style: none none none solid; border-left-width: 1pt; border-left-color: rgb(204, 204, 204); padding: 0in 0in 0in 6pt; margin-left: 4.8pt; margin-right: 0in;" class=""><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">>> Note that -Wformat isn't meant to be a general portability checker, since it<br class="">>> only ever raises warnings when there's a type mismatch *on the current<br class="">>> target*, not if there's any possibility of a mismatch.<br class="">><br class="">> It's (mostly) not trying to be clever; it's just checking what the<br class="">> standard requires. Printing an int with %ld is wrong according to the<br class="">> standard even if int and long are the same size on the target.<br class=""></span></div></div></div></blockquote></div></div></div></blockquote><div><br class=""></div><div>Many things are wrong according to the standard and we don’t warn about it because the standard is being silly. In this case I don’t see a technical reason why integral types with matching sizeof and signed-ness should be incompatible. There is a portability problem if you recompile and the platform doesn’t make sure the format specifier and integral types aren’t in sync, but as explained in the patch that’s guaranteed to work on Darwin platforms.</div><div><br class=""></div><div>We can be standards pedants, or we can accept that this case is actually OK according to the platform.</div><div><br class=""></div><div>I could also get the standard changed, but that’ll take a while and I’m not sure it’s worthwhile.</div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class="WordSection1" style="page: WordSection1; 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;"><div class=""><div class=""><blockquote style="border-style: none none none solid; border-left-width: 1pt; border-left-color: rgb(204, 204, 204); padding: 0in 0in 0in 6pt; margin-left: 4.8pt; margin-right: 0in;" class=""><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">>> For example, you<br class="">>> could be printing out a size_t using %lu, and you wouldn't get warnings if<br class="">>> your compilation target used unsigned long as the underlying type for<br class="">>> size_t, even though that underlying type could differ across targets.<br class="">><br class="">> Right, because doing this kind of portability checks would be hard:<br class="">> the compiler can't know if the source used unsigned long and was lucky<br class="">> that it matched size_t, or if unsigned long had been carefully<br class="">> selected to match.<br class="">><br class="">>> This<br class="">>> proposal does mean we would lose out on some additional portability<br class="">>> warnings; continuing the previous example, we would now not get warnings for<br class="">>> printing out a size_t using %lu even for a compilation target where size_t<br class="">>> was actually an unsigned int, assuming that the target had the same size and<br class="">>> alignment for int and long (as most 32-bit platforms do). However, given<br class="">>> that -Wformat was never meant to be a general portability checker, and that<br class="">>> there would still be an option to get the fully strict warnings, I don't<br class="">>> think this is too much of an issue in practice.<br class="">><br class="">> I prefer to think of them as correctness warnings rather than<br class="">> portability warnings. I'm not buying the argument that because it<br class="">> doesn't catch all portability issues, it shouldn't warn about<br class="">> incorrect code.<br class=""></span></div></div></div></blockquote></div></div></div></blockquote><div><br class=""></div><div>In the very specific case of NSInteger and %z on Darwin platforms, do we agree there’s no correctness issue? I’m not talking standards correctness, I’m talking “the code does what’s expected”.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class="WordSection1" style="page: WordSection1; 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;"><div class=""><div class=""><blockquote style="border-style: none none none solid; border-left-width: 1pt; border-left-color: rgb(204, 204, 204); padding: 0in 0in 0in 6pt; margin-left: 4.8pt; margin-right: 0in;" class=""><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">>> What are people's thoughts here? Are there preferences for relaxing -Wformat<br class="">>> and adding a new option for strict format warnings vs. keeping -Wformat<br class="">>> as-is and adding a new option for relaxed format warnings? Of course, we<br class="">>> should also ensure that the optimizer doesn't do anything surprising when<br class="">>> there's a type mismatch between the specifier and the argument but both<br class="">>> types have the same size and alignment (i.e., the case where the relaxed<br class="">>> format warning won't fire), both now and in the future.<br class="">><br class="">> I would prefer not to relax -Wformat by default. I think what it's<br class="">> doing is simple and correct, and a large amount of code compiles with<br class="">> it.<br class=""></span></div></div></div></blockquote></div></div></div></blockquote><div><br class=""></div><div>We’d be relaxing something that only just got added to clang, and which tries to catch portability issues. It’s evidently not doing this very well because it doesn’t know about platform guarantees. It’s a useful warning in general, but the false positive rate is high, at least on Darwin platforms. That’s why I want to “relax” -Wformat: because it’s noisy and people will ignore it.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class="WordSection1" style="page: WordSection1; 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;"><div class=""><div class=""><blockquote style="border-style: none none none solid; border-left-width: 1pt; border-left-color: rgb(204, 204, 204); padding: 0in 0in 0in 6pt; margin-left: 4.8pt; margin-right: 0in;" class=""><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">> I'm not opposed to adding a -Wformat-relaxed option if there's a lot<br class="">> of demand for it.<br class=""></span></div></div></div></blockquote></div></div></div></blockquote><div><br class=""></div><div>I’m opposed to having these format portability warnings on with -Wall. -Wall shouldn’t be erroneously noisy.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class="WordSection1" style="page: WordSection1; 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;"><div class=""><div class=""><blockquote style="border-style: none none none solid; border-left-width: 1pt; border-left-color: rgb(204, 204, 204); padding: 0in 0in 0in 6pt; margin-left: 4.8pt; margin-right: 0in;" class=""><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">> TL;DR: What Joerg said.<br class="">><br class="">> Thanks,<br class="">> Hans<br class="">> _______________________________________________<br class="">> cfe-dev mailing list<br class="">><span class="Apple-converted-space"> </span></span><a href="mailto:cfe-dev@lists.llvm.org" style="color: purple; text-decoration: underline;" class=""><span class="">cfe-dev@lists.llvm.org</span><span class=""></span></a><span class=""><br class="">><span class="Apple-converted-space"> </span></span><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Ddev&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=Dc2LUIK-XaYupO2Hkkb0rUQ1P7J1i_d1FWGuq9xVIPo&s=235uPgu-k8-11nIEt_1Br4jxzCB_Oj0sZboRl8d5uwo&e=" target="_blank" style="color: purple; text-decoration: underline;" class=""><span class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</span><span class=""></span></a><span class=""><br class="">_______________________________________________<br class="">cfe-dev mailing list<br class=""></span><a href="mailto:cfe-dev@lists.llvm.org" style="color: purple; text-decoration: underline;" class=""><span class="">cfe-dev@lists.llvm.org</span><span class=""></span></a><span class=""><br class=""></span><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Ddev&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=Dc2LUIK-XaYupO2Hkkb0rUQ1P7J1i_d1FWGuq9xVIPo&s=235uPgu-k8-11nIEt_1Br4jxzCB_Oj0sZboRl8d5uwo&e=" target="_blank" style="color: purple; text-decoration: underline;" class=""><span class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</span><span class=""></span></a><span class=""><o:p class=""></o:p></span></div></div></div></blockquote></div><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div></div></div><span 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; float: none; display: inline !important;" class="">_______________________________________________</span><br 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=""><span 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; float: none; display: inline !important;" class="">cfe-dev mailing list</span><br 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=""><span 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; float: none; display: inline !important;" class=""><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a></span><br 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=""><span 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; float: none; display: inline !important;" class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a></span></blockquote></div><br class=""></body></html>