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

Arthur O'Dwyer arthur.j.odwyer at gmail.com
Tue Nov 26 08:46:34 PST 2013


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




More information about the cfe-commits mailing list