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

[Alp Toker]

On 26/11/2013 21:53, Arthur O'Dwyer 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).

Arthur, thanks for providing this very clear analysis of the situation 
which was missing so far.

I don't know enough about the format specifiers to comment on this but 
it's definitely on topic and something we can work through together, 
especially if we're moving forward C1y on the side.

>
> 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.

Let's keep it on list and avoid spawning off-list discussions until 
there's a course of action, but try to keep it contained to this thread 
so people can tune out if they want. It is after all directly related to 
one of the big "selling points" of clang, namely fantastic format 
specifier checking.

One of the problems with the original patch was that it didn't have much 
context and people were trying to review it even after a newer version 
was posted to a separate thread. That, along with having non-standard 
extensions proposed without being subscribed to the list tend to send 
warning signals during patch review. On the other hand, having a proper 
discussion like this has been reassuring even if we don't ultimately get 
answers to all your questions, I'd be more comfortable with the proposed 
changes because the background and intent are now out in the open.

Alp.



>
> –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-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

-- 
http://www.nuanti.com
the browser experts