I would love to see the printf attribute code generalised so that we could have a pragma to declare a formatting character and the type it expected. For the FreeBSD kernel, we have a set of printf extensions for printing complex data structures, and a lot of modern libc implementations provide a mechanism for registering handlers for format strings. It would be great if all of these could be supported, without hard-coding them.
David On 26 Nov 2013, at 21:53, Arthur O'Dwyer <[email protected]> wrote: > [cc: cfe-dev, which I don't subscribe to] > > Background: Jonathan Schleifer proposed a patch to add new format > specifiers %k/%K or %C/%S to print respectively single characters or > null-terminated strings of type "of_char32_t", which is a typedef for > char32_t (which in C is a typedef for uint_least32_t and in C++ is a > separate built-in character type). > > Discussing offline, Jonathan seemed to agree (reluctantly ;)) with my > reaction that this patch was really needed only to paper over a > problem with the latest C and C++ standards — namely, that they > provide these new character types "char16_t" and "char32_t" but don't > provide any printf or scanf specifiers for them. This is inconsistent > with the previous standard's "wchar_t", which got its own "%lc" and > "%ls" format specifiers. > > I propose that it would be a very good idea for the next standard to > provide format specifiers for char16_t and char32_t. I would nominate > "%hc" (char16_t) and "%Lc" (char32_t), and the matching "%hs" (array > of char16_t) and "%Ls" (array of char32_t). > > Questions: > > (A) Does this proposal step on the toes of any existing proposal — > e.g., is "printing char32_t" already in the pipeline to be fixed in > C1y? I'm only vaguely aware of the stuff going into C++1y and I don't > follow C1y at all. > > (B) Would Jonathan's -Wformat patch find greater acceptance if ObjFW's > OFString formatting functions adopted the %Lc/%Ls syntax instead of > the previously proposed %C/%S? (However, I believe Jonathan is right > about still needing a new __attribute__((format(__OFString__,1,2))) to > deal with some other things.) > > (C) I'm sure I'll be told anyway ;) but where would be a proper forum > to bring this up with an eye to standardization? We've got a > complicated dance here among Clang, Apple's libc, Apple's NSLog, GCC, > glibc, the C committee, and probably some others I've forgotten. My > primary goal here is really to convince someone one step closer to to > the C committee that this would be a good idea and they should > champion it in the committee. :) > > Feel free to contact me offline if you don't want to spam the list. > > –Arthur > > > On Tue, Nov 26, 2013 at 8:46 AM, Arthur O'Dwyer > <[email protected]> wrote: >> On Tue, Nov 26, 2013 at 3:18 AM, Jonathan Schleifer <[email protected]> wrote: >>> >>> So, why is this not generalized enough? It offers a new format string type, >>> what >>> more could I do? If another framework emerges, it would need to add its own >>> format string type. There is no way around it. It might use other types for >>> %C >>> and %S, etc. >> >> I think Jonathan's current patch is probably the most "Clang-like" way >> of doing it, but there *is* at least one more option: we could expose >> the set of printf format specifiers directly to the user and allow the >> user to customize it via the command line. For example, >> >> clang -fprintf-support=std test.c // warns on %I64 and %C >> clang -fprintf-support=std,objc test.c // warns on %I64 >> clang -fprintf-support=std,objc,win32 test.c // warns on %K and %{ >> clang -fprintf-support=std,objfw,gnu test.c // warns on %I64 >> again but not %K or %{ >> clang -fprintf-support=c89 test.c // warns on %zu but not %u >> >> and so on. The defaults could be set according to the language and/or >> -fobjc-runtime= flags, but the user could override them; for example, >> maybe he's got a lot of Win32 code (using %I32) in his codebase, which >> is going to be compiled even though it's dead; he doesn't want to see >> warnings on %I32, so he adds "win32" to his list of -fprintf-support= >> flags. >> >> The main problem with this idea, IMHO, is that I haven't dealt with >> functions like ObjC's NSLog() which must be allowed to take %@ even >> though ObjC's regular printf() is *not* allowed to take %@. So it >> seems that __attribute__((printf,__NSString__)) is still required. >> >>> Therefore, I think adding a new format string type is the right and only >>> sane way. >> >> Oh, or *alternatively*, Jonathan, you could rework your runtime's >> Unicode support so that you can use the existing format specifiers and >> not need to change the API at all! What's wrong with wchar_t, %lc, and >> %ls again...? (Feel free to take this part off-list. I think it's a >> valid solution, but there may be technical reasons against it?) >> >> –Arthur > > _______________________________________________ > cfe-dev mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
