[cfe-dev] [PATCH] Let __attribute__((format(…))) accept OFStrings

[David Chisnall]

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 <arthur.j.odwyer at gmail.com> 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
> <arthur.j.odwyer at gmail.com> wrote:
>> On Tue, Nov 26, 2013 at 3:18 AM, Jonathan Schleifer <js at webkeks.org> 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
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev