[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-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
