Am 26.11.2013 um 17:46 schrieb Arthur O'Dwyer <[email protected]>:
> 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
Well, this is only half a solution, because currently, there *is* a difference
between
__attribute__((format(printf, 1, 2)))
and
__attribute__((format(__NSString__, 1, 2))).
The former wants a C string to be passed to printf. %C and %S are treated like
they are specified in POSIX: They are aliases for %lc and %ls.
Now, when the format is NSString, 3 things are different:
* The format string is an NSString, which means it is an object.
* The format string allows %@, which means the parameter is an object.
* The format string treats %C and %S differently. It considers them to be of
type unichar, which is a Cocoa type.
> 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 thing about win32 I like :). But I think this could also be done depending
on the target?
> 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.
Exactly! That's the point why there is a new format string type __NSString__.
And that's why I want to do the same for __OFString__. Especially as it's
possible to use Cocoa and ObjFW in the same source file (the usual case is
connecting the internal, portable core with the platform specific Cocoa UI).
> 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?)
Well, first of all, there's problem 1: Clang needs to accept an OFString as a
format specifier. Otherwise, a format string cannot be an ObjFW object. If
Clang accepts an OFString for type __NSString__, we're at problem 2:
__NSString__ handles %C and %S differently, thinking it is of type unichar, a
Cocoa-specific type which is defined to unsigned short.
So, now there are two solutions: The one my patch implements (treating it as
of_unichar_t, which is char32_t) or changing my framework. The latter sounds
easier at first, but actually isn't: While Cocoa can only handle UCS-2 and thus
only the BMP of Unicode, ObjFW uses UCS-4, so all Unicode characters can be
used. So a unichar can't store e.g. an Emoji, while an of_unichar_t can. Cocoa
uses UTF-16 to work around this, but it's not possible anymore to store an
Emoji in a single character.
I hope this explains why changing it to use the type unichar in ObjFW is not an
option. Even if that would work, problem 1 would still exist.
Therefore, I think adding a new format string type is a sane solution to solve
1 and 2 that a.) works in any case (e.g. ObjFW with Apple runtime) b.) does not
affect anybody else.
--
Jonathan
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
