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

[Jonathan Schleifer]

Am 26.11.2013 um 00:32 schrieb Alp Toker <alp at nuanti.com>:

> OK, my feeling is still that this should be generalised a little, because there are clearly multiple runtimes that can benefit from an attribute rather than hard-coding class names. This wasn't addressed by your newer patch.

Because this is nonsense. This is not runtime-related, but framework-related. You can use ObjFW with the Apple runtime. You can use ObjFW with the ObjFW runtime. You can use GNUstep with the GCC runtime. You can use GNUstep with the GNUstep runtime. The classes are part of the framework and thus completely independent from the runtime. If I would hard code those changes to the ObjFW runtime part in Clang, it would break when using ObjFW with the Apple runtime - which is the default on Apple platforms.

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.

The only other option would be to add more -fobjc-foo options - which back then nobody wanted. The ObjFW runtime class in Clang was only created because I wanted to add an option -fobjc-direct-class-refs, but new options weren't welcome, so -fobjc-runtime=objfw was added instead. So adding a new option might not be the best idea, considering that almost everybody was against adding a new option.

Therefore, I think adding a new format string type is the right and only sane way. ESPECIALLY as %C and %S are handled differently for NSString and OFString - so it really is not just a different name! It really *is* another format string type!

> Also, rjmccall isn't around so much these days so you may need to negotiate a new deal :-)

What exactly is wrong with the deal? The code is already in for more than a year, it works well, it doesn't hurt anybody or break anything for somebody else and everybody is happy. So where is the problem? I have good reachability via mail, I maintain my changes myself, I regularly build LLVM and Clang trunk to see if it still works. Is your problem with the situation that I can't commit maintenance patches myself and that I need to send those patches to the mailing list? I'd be more than happy to commit maintenance patches myself if I had commit access.

So, what do you suggest with the patch? If it is technically ok, I'm really for committing it, as this is the clean and sane solutions. Making this runtime-dependant is the wrong way as this is framework-dependant. Making it another -fobjc-foo option is wrong because we don't want yet another option and because it's more than just a different name, it uses a different format string. So, if it uses a different format string, what's wrong with having a new format string type?

--
Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131126/cb533e36/attachment.sig>