Le 26 nov. 2013 à 18:35, Jonathan Schleifer <[email protected]> a écrit :
> 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. That's a rather strange way to express it. UTF-16 is not more a workaround than UTF-32 or UTF-8. They are all first class encodings. Cocoa supports all Unicode planes and encode them using UTF-16 (or even ASCII internally) which is generally far more space efficient than using UTF-32. FWIW, it is even possible to use emoji in constant NSString generated at compilation time. So telling that Cocoa can only handle UCS-2 is plainly wrong. > 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 > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits -- Jean-Daniel _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
