<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr">Hey Arthur,</div><div dir="ltr"><br></div><div dir="ltr">I really like your idea to just use the regular printf format attribute for all formats.</div><div dir="ltr"><br></div><div dir="ltr">We can wrap the wprintf attribute as well in the same logic, all we’d have to check is that the format argument is a literal, a string, and that the strings designated type (via u8, u, U, L, etc prefixes) match the actual type expected by printf.</div><div dir="ltr"><br></div><div dir="ltr">As for changing the length modifiers to U16, U32, etc sure it’s kinda disappointing, but it’s doable.</div><div dir="ltr"><br><blockquote type="cite">On Mar 25, 2020, at 1:53 PM, Arthur O'Dwyer via cfe-dev <cfe-dev@lists.llvm.org> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Wed, Mar 25, 2020 at 12:59 PM Aaron Ballman via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><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">On Wed, Mar 25, 2020 at 11:51 AM Marcus Johnson <<a href="mailto:marcusljohnson1991@gmail.com" target="_blank">marcusljohnson1991@gmail.com</a>> wrote:<br>
> > That doesn't answer why we need a new format archtype. The archtypes<br>
> > are used because we want the check to model behavior specific to some<br>
> > API. If I understand your proposal properly, you're not proposing to<br>
> > add anything like uprintf() to a C library (and such an API doesn't<br>
> > already exist), so adding a new archtype surprises me. I would have<br>
> > thought the existing archtypes would suffice, but maybe I'm still<br>
> > misunderstanding a part of your proposal.<br></blockquote><div><br></div><div>In particular, if all you want to do is support `__attribute__((format(printf, x, y)))` on function parameters that happen to be of type `char8_t*`, `char16_t*` or `char32_t*`, that should be trivial. Just look at how Clang works for arguments of type `wchar_t*` and copy that.</div><div><br></div><div>...Oh wait, it looks like neither GCC nor Clang actually implement format-string checking for wchar_t format strings!</div><div><a href="https://godbolt.org/z/Tk9YCA">https://godbolt.org/z/Tk9YCA</a><br></div><div><br></div><div> std::wprintf("%s", 42); // no diagnostic emitted</div><div><br></div><div>So that would be a <i><b>very</b></i> good place to start, IMO. Once the code is in place to format-check wide string literals, it should be trivial to extend it to also format-check char{8,16,32}_t literals.</div><div>Here's the existing bug report: <a href="https://bugs.llvm.org/show_bug.cgi?id=16810">https://bugs.llvm.org/show_bug.cgi?id=16810</a></div><div><br></div><div><i><b>Orthogonally</b></i>, you seem to be proposing that there should be some new printf format specifiers besides %s %c %[ (for char) and %ls %lc %l[ (for wchar_t). This is not a Clang issue; this is a library-design issue that you should think about as you write your library function that takes a format string (you know, the one you want to apply __attribute__((format)) to). If you are not writing a library function, then you have nothing to apply the attribute to, and therefore there's no reason for you to need <i>anything</i> changed.</div><div>You throw out the ideas of %us for char16_t, %Us for char32_t, and have no suggestion for char8_t. However, you cannot use %us as a format specifier, because printf already gives that sequence a valid meaning:</div><div><br></div><div> printf("hello %us world", 42u); // prints "hello 42s world"</div><div><br></div><div>My off-the-top-of-my-head idea is that you should take a hint from MSVC; they provide %I32d, %I64d, etc., for integer types, so how about %C8s, %C16s, and %C32s for Unicode character string types? However, again, this is an issue to think about as you design your `MyPrintfLikeFunction` within your own codebase. Maybe you'll find that you don't even need a format specifier for those types.</div><div><br></div><div>(FWIW, the C and C++ party line seems to be that no "%C16s" or "%C32s" is needed, because the modern approach is to separate transcoding from output. You shouldn't be printf'ing Unicode strings directly; you should be first transcoding them into `char` or `wchar_t` strings, and then printf'ing or wprintf'ing those strings. Personally I don't think that approach is very helpful in practice, though.)</div><div><br></div><div>–Arthur</div></div></div></div></div>
<span>_______________________________________________</span><br><span>cfe-dev mailing list</span><br><span>cfe-dev@lists.llvm.org</span><br><span>https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</span><br></div></blockquote></body></html>