
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>Le 21 janv. 2012 à 06:09, Ted Kremenek a écrit :</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><br>On Jan 20, 2012, at 5:36 PM, Jean-Daniel Dupas wrote:<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">Le 21 janv. 2012 à 02:07, Eli Friedman a écrit :<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">On Fri, Jan 20, 2012 at 5:03 PM, Jean-Daniel Dupas<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><<a href="mailto:devlists@shadowlab.org">devlists@shadowlab.org</a>> wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Le 20 janv. 2012 à 23:44, Eli Friedman a écrit :<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On Fri, Jan 20, 2012 at 2:09 PM, Jean-Daniel Dupas<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><<a href="mailto:devlists@shadowlab.org">devlists@shadowlab.org</a>> wrote:<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Hi,<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Actually, clang automatically add a "format(printf)" attribute to the declarations of NSLog/NSLogv functions.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">This is actually wrong, as NSLog expect an NSString format attribute. It is not really an issue as the code that checks the format string is the same for printf and NSString,<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">but actually I'm working on adding support for CFString format, and having the wrong tag on NSLog functions prevent some code factoring between CFString and NSString format checking.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Now that NSString format is properly checked, this trick is no longer needed, so I'd like to stop forcing the type to printf, and use NSString instead.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">This patch also reduce the scope of this hack to objc code only (so if by any change someone write a C library with an NSLog function, clang will not try to tag it with an NSString format attribute).<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">If you're going to be in the area anyway, can you get rid of the hack<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">altogether and add definitions of these functions into Builtins.def?<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">These functions shouldn't need any special logic.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">-Eli<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I have nothing against completely removing this hack, especially as these functions are properly declared in the Foundation headers,<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">but is it worth putting a definition in Builtins.def ? Unlike other objc functions defined in Builtins.def, NSLog functions are not part of the runtime.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Strictly speaking, it isn't, but we're already pretending it is anyway<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">by marking it with a format attribute, no?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">-Eli<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Yes, we were doing it. My question was more "Is there any good reason to continue to pretend it" ?<br></blockquote><blockquote type="cite">I just don't know why they where hard-coded in the first place.<br></blockquote><br>I don't remember why it was done this way, but Eli's suggestion is the right approach.<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">Anyway, I will have a look at what should be done to add them in Builtins.def. It will require a little work as the string format used to defined the attributes does not support 'NSString' format out of the box.<br></blockquote><blockquote type="cite">It supports only printf and scanf currently.<br></blockquote><br>Yes, it should be enhanced to support the NSString format.<br></div></blockquote><div><br></div><div>I have a first patch that add NSLog/NSLogv to Builtins.def, but instead of adding a new letter to define NSString format attribute, I enhance the <span class="Apple-style-span" style="font-family: Menlo; font-size: 11px; ">AddKnownFunctionAttributes</span><span class="Apple-style-span" style="background-color: transparent;"> function to automatically specify "NSString" format inste</span>ad of "printf" format when the format parameter is an objc object.</div></div><div><br></div><div>This patch also remove trailing '/' in front of objc header names in Builtins.def. It prevents message like "include </obj/objc-exception.h>" in diagnostics.</div><br><div apple-content-edited="true">

<div>-- Jean-Daniel</div><div><br></div><div><br></div><br class="Apple-interchange-newline">

</div>

</body></html>