Re: [PATCH] Let __attribute__((format(…))) accept OFStrings

[Arthur O'Dwyer]

[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