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
<[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
--
http://www.nuanti.com
the browser experts
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
