<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Sorry, forgot to report the bug number… Here it is:<div><br></div><div><a href="http://llvm.org/bugs/show_bug.cgi?id=11442">http://llvm.org/bugs/show_bug.cgi?id=11442 </a></div><div><br></div><div>A</div><div><br></div><div><div><div>On 27 Nov 2011, at 18:00, <a href="mailto:cfe-dev-request@cs.uiuc.edu">cfe-dev-request@cs.uiuc.edu</a> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Send cfe-dev mailing list submissions to<br><span class="Apple-tab-span" style="white-space:pre"> </span><a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br><br>To subscribe or unsubscribe via the World Wide Web, visit<br><span class="Apple-tab-span" style="white-space:pre"> </span>http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev<br>or, via email, send a message with subject or body 'help' to<br><span class="Apple-tab-span" style="white-space:pre"> </span>cfe-dev-request@cs.uiuc.edu<br><br>You can reach the person managing the list at<br><span class="Apple-tab-span" style="white-space:pre"> </span>cfe-dev-owner@cs.uiuc.edu<br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of cfe-dev digest..."<br><br><br>Today's Topics:<br><br> 1. Re: bug reporting for libclang (Ted Kremenek)<br> 2. Re: Implementation of IO2BO Dynamic Checks (Ted Kremenek)<br> 3. New comer's problem: library link error of a clang example<br> (susangao)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Sun, 27 Nov 2011 07:23:19 -0800<br>From: Ted Kremenek <kremenek@apple.com><br>Subject: Re: [cfe-dev] bug reporting for libclang<br>To: unitydeveloper <alessandro@runpresto.com><br>Cc: Argyrios Kyrtzidis <kyrtzidis@apple.com>,<span class="Apple-tab-span" style="white-space:pre"> </span>"cfe-dev@cs.uiuc.edu<br><span class="Apple-tab-span" style="white-space:pre"> </span>Developers" <cfe-dev@cs.uiuc.edu><br>Message-ID: <E114A026-5044-4D3D-81D2-6B937A0CB26F@apple.com><br>Content-Type: text/plain; CHARSET=US-ASCII<br><br>Hi Alessandro,<br><br>This is the right place to raise awareness of such issues.<br><br>#1 sounds like a general crash issue in the frontend. That's a general problem that just needs to be fixed. Please file bug report for #1 at:<br><br> http://llvm.org/bugs/<br><br>and please email the list with the Problem Report #.<br><br>Without more information, I'm not sure if #2 is a bug or a general performance issue that needs to be improved. I think it possibly depends on what is being pulled in by your .h file, and I'm not certain how libclang generates precompiled preambles for arbitrary .h files. Can you provide a bit more information on what exactly you are doing in #2? That will help us determine if you are using the API's correctly or if this really is a major performance bug (my suspicion is the latter).<br><br>Thanks so much,<br>Ted<br><br>On Nov 27, 2011, at 5:10 AM, unitydeveloper wrote:<br><br><blockquote type="cite">Hi there,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">first of all please excuse me if this is not the right place for bug reporting and be so kind to redirect me to the apposite place.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I am using lib clang ( clang version 3.1 (trunk 144457) ) to build a code editor on OSX.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">It works pretty well with objective c files ( I didn't test it with C/C++/ObjC++ yet ). I noticed two quite strange behaviours though:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">1) when I type a single column ( ':' ) character inside the implementation of a class in an objective-C (.m) file, clang_reparseTranslationUnit() sends a signal and terminates the program. I can send the source code and instructions to reproduce the bug if needed.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">2) the clang_reparseTranslationUnit() seems to be much much faster on .m files than on .h files, so much that live lexical colouring (using only clang_tokenize(), not even clang_annotateTokens() )is very slow on .h files, while it easily keeps up with my typing speed with a much longer .m file that includes that very same .h file.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Is there any special procedure for speeding the parsing/tokenizing of .h files up?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Thank you very much,<br></blockquote><blockquote type="cite">Alessandro Pistocchi<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On 26 Nov 2011, at 18:00, cfe-dev-request@cs.uiuc.edu wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">Send cfe-dev mailing list submissions to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span class="Apple-tab-span" style="white-space:pre"> </span>cfe-dev@cs.uiuc.edu<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">To subscribe or unsubscribe via the World Wide Web, visit<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span class="Apple-tab-span" style="white-space:pre"> </span>http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">or, via email, send a message with subject or body 'help' to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span class="Apple-tab-span" style="white-space:pre"> </span>cfe-dev-request@cs.uiuc.edu<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">You can reach the person managing the list at<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span class="Apple-tab-span" style="white-space:pre"> </span>cfe-dev-owner@cs.uiuc.edu<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">When replying, please edit your Subject line so it is more specific<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">than "Re: Contents of cfe-dev digest..."<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Today's Topics:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> 1. Re: how to dump/trace the include path to a previous<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> definition (Matthieu Monrocq)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> 2. Re: how to dump/trace the include path to a previous<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> definition (Philip Ashmore)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">----------------------------------------------------------------------<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Message: 1<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Date: Fri, 25 Nov 2011 19:43:46 +0100<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">From: Matthieu Monrocq <matthieu.monrocq@gmail.com><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Subject: Re: [cfe-dev] how to dump/trace the include path to a<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span class="Apple-tab-span" style="white-space:pre"> </span>previous<span class="Apple-tab-span" style="white-space:pre"> </span>definition<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">To: Philip Ashmore <contact@philipashmore.com><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Cc: cfe-dev@cs.uiuc.edu<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Message-ID:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span class="Apple-tab-span" style="white-space:pre"> </span><CAKE6RfgSsP4Dkr9a8uU3RPsTF9LtDfNkAaQSzYvYgwUMi4x58A@mail.gmail.com><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Content-Type: text/plain; charset="iso-8859-1"<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Le 25 novembre 2011 04:16, Philip Ashmore <contact@philipashmore.com> a<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">?crit :<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Hi there.<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">Is there a way to get clang to store/dump the include path to previous<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">definitions/typedefs?<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">Saying that A, defined in file B, line C was previously defined in file<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">B, line C isn't helpful.<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 know, I know, "don't include the same header file twice" but I have<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">good reasons to do so.<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">Details:<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 several projects that use header files to do the "C" equivalent<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">of class template definitions.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">The "templates" are things like AVL trees, and the "classes" are<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">instantiations of the template with #defines standing in for template<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">arguments.<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">This approach is currently the only way I can get multiple instances of<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">the same template into a translation unit without name clashes - I wish<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">there was a better way.<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">Unfortunately this approach isn't without its problems.<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">My next release will include the project files using "-I\${top_srcdir}"<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">instead of "-isystem ${top_srcdir}" and this has uncovered problems now<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">that the compiler knows the project include files are not system headers.<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">The one I'm stumped by is typedef redefinitions caused by multiple<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">inclusion from the same include file.<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'm sure a solution to this problem would be of use to others too - I'm<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">not the only one who uses tricks like this.<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">Regards,<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Philip Ashmore<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Is there any special reason that you would use:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">#include "mytrick.h"<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Instead of a regular macro invitation with arguments:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">MY_TRICK()<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Clang would deal with the latter very nicely, especially since Chandler<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">worked out the macro expansion in diagnostics.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">-- Matthieu<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">-------------- next part --------------<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">An HTML attachment was scrubbed...<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20111125/e7424fe5/attachment-0001.html <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">------------------------------<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Message: 2<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Date: Fri, 25 Nov 2011 21:06:01 +0000<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">From: Philip Ashmore <contact@philipashmore.com><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Subject: Re: [cfe-dev] how to dump/trace the include path to a<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span class="Apple-tab-span" style="white-space:pre"> </span>previous<span class="Apple-tab-span" style="white-space:pre"> </span>definition<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">To: Matthieu Monrocq <matthieu.monrocq@gmail.com>, cfe-dev@cs.uiuc.edu<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Message-ID: <4ED00339.9060201@philipashmore.com><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">On 25/11/11 18:43, Matthieu Monrocq 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"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Le 25 novembre 2011 04:16, Philip Ashmore <contact@philipashmore.com <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><mailto:contact@philipashmore.com>><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">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"> Hi there.<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"> Is there a way to get clang to store/dump the include path to previous<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> definitions/typedefs?<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"> Saying that A, defined in file B, line C was previously defined in<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> file<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> B, line C isn't helpful.<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 know, I know, "don't include the same header file twice" but I have<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> good reasons to do so.<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"> Details:<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 several projects that use header files to do the "C" equivalent<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> of class template definitions.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> The "templates" are things like AVL trees, and the "classes" are<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> instantiations of the template with #defines standing in for template<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> arguments.<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"> This approach is currently the only way I can get multiple<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> instances of<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> the same template into a translation unit without name clashes - I<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> wish<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> there was a better way.<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"> Unfortunately this approach isn't without its problems.<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"> My next release will include the project files using<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> "-I\${top_srcdir}"<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> instead of "-isystem ${top_srcdir}" and this has uncovered<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> problems now<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> that the compiler knows the project include files are not system<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> headers.<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"> The one I'm stumped by is typedef redefinitions caused by multiple<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> inclusion from the same include file.<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'm sure a solution to this problem would be of use to others too<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> - I'm<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> not the only one who uses tricks like this.<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"> Regards,<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> Philip Ashmore<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"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Is there any special reason that you would use:<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">#include "mytrick.h"<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">Instead of a regular macro invitation with arguments:<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">MY_TRICK()<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">?<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">Clang would deal with the latter very nicely, especially since <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Chandler worked out the macro expansion in diagnostics.<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">-- Matthieu<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Here are a few reasons off the top of my head:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">1. Putting code inside a macro makes debugging almost impossible<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">2. some parts of the include file are conditional, surrounded with #if #endif<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> I'll grant you that macro name munging so that the excluded code is in the "off"<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> branch, but then we're back to (1)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">3. I reported a bug about a problem with cpp's macro expansion -<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> "cpp-4.4: incorrect macro expansion when a macro call results in the same macro being called"<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590008<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I know I can do the clang -E trick to examine the preprocessed output, but since clang is<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">all about useful and descriptive diagnostics, I thought that a check that something being<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">redefined by the same file/line to prompt a backtrace of the previous definition would save<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">me and others from the trouble - yet another reason to use clang.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Philip<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">------------------------------<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">_______________________________________________<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">cfe-dev mailing list<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">cfe-dev@cs.uiuc.edu<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">End of cfe-dev Digest, Vol 53, Issue 86<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">***************************************<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">cfe-dev mailing list<br></blockquote><blockquote type="cite">cfe-dev@cs.uiuc.edu<br></blockquote><blockquote type="cite">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev<br></blockquote><br><br><br>------------------------------<br><br>Message: 2<br>Date: Sun, 27 Nov 2011 08:59:33 -0800<br>From: Ted Kremenek <kremenek@apple.com><br>Subject: Re: [cfe-dev] Implementation of IO2BO Dynamic Checks<br>To: Benjamin Schulz <bjs428@mail.missouri.edu><br>Cc: cfe-dev@cs.uiuc.edu<br>Message-ID: <68130779-4105-4A85-97E3-041E883FB6E7@apple.com><br>Content-Type: text/plain; CHARSET=US-ASCII<br><br>Hi Ben,<br><br>I could be mistaken, but I'm not aware of this work (IntPath) being integrated into Clang mainline, nor efforts from the authors to push it into mainline at this time.<br><br>There's a general interest in having work like this pushed back to mainline if (a) the quality of the code is up the standard of the codebase and (b) the work will be maintained after the initial check-in.<br><br>Cheers,<br>Ted<br><br>On Nov 22, 2011, at 1:59 PM, Benjamin Schulz wrote:<br><br><blockquote type="cite">-----BEGIN PGP SIGNED MESSAGE-----<br></blockquote><blockquote type="cite">Hash: SHA1<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Hi all,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I noticed some recent research by Zhang et al on the insertion of<br></blockquote><blockquote type="cite">dynamic checks for integer-overflow-to-buffer-overflow (IO2BO)<br></blockquote><blockquote type="cite">vulnerabilities[1]. It looks like Zhang et al's implementation already<br></blockquote><blockquote type="cite">happens to use the LLVM framework, and I was wondering if any work has<br></blockquote><blockquote type="cite">been done to incorporate a feature like this into the trunk of Clang.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">If so, could someone point me to where the code lives in the SVN tree?<br></blockquote><blockquote type="cite">If not, is anyone out there on the list doing something similar as a<br></blockquote><blockquote type="cite">side-project?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Much thanks,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">- --Benjamin Schulz<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">* * *<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">[1] Zhang, Chao, Tielie Wang, Tao Wei, Yu Chen, and Wei Zou. "IntPath:<br></blockquote><blockquote type="cite">Automatically Fix Integer-Overflow-to-Buffer-Overflow Vulnerability at<br></blockquote><blockquote type="cite">Compile-Time". ESORICS 2010.<br></blockquote><blockquote type="cite">-----BEGIN PGP SIGNATURE-----<br></blockquote><blockquote type="cite">Version: GnuPG v1.4.10 (GNU/Linux)<br></blockquote><blockquote type="cite">Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">iQEcBAEBAgAGBQJOzBtWAAoJECT8Sbi31ptpuC0IAK2PrMbvJqgNyBx54CdfIb4i<br></blockquote><blockquote type="cite">Cwqgn1boP9tCB4+KH+jrRj9LaT8ZJmSnx+Nb725HjmhWBCS1mRDtL8qq+s11XMZQ<br></blockquote><blockquote type="cite">Nyh88Qj+uiPdf6Ok1YKlZOHosg6UNjLoE4twLENFbfU/lqN9baTt9u+Zc0ioaUA1<br></blockquote><blockquote type="cite">lJZVXrKCifytUKr6Ji0IMs8t4tTsU5XeyTRETisjBj1DruYPy2sZOdWPyqMv6tB0<br></blockquote><blockquote type="cite">fxVoruSyhj/ZIfNnhzXLJzhO30TJRrCYBsPmp2WyZTenj0HW7VqNqgRkgonDJNOk<br></blockquote><blockquote type="cite">uOMjFpzfgtHrAxVuyfuldyZJ98kOkXDSaXGPYwxBPnEqU2aEAq6L4/Y4EzBbHew=<br></blockquote><blockquote type="cite">=+XxK<br></blockquote><blockquote type="cite">-----END PGP SIGNATURE-----<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">cfe-dev mailing list<br></blockquote><blockquote type="cite">cfe-dev@cs.uiuc.edu<br></blockquote><blockquote type="cite">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev<br></blockquote><br><br><br>------------------------------<br><br>Message: 3<br>Date: Wed, 23 Nov 2011 18:46:08 -0800 (PST)<br>From: susangao <gaoshuang@gmail.com><br>Subject: [cfe-dev] New comer's problem: library link error of a clang<br><span class="Apple-tab-span" style="white-space:pre"> </span>example<br>To: cfe-dev@cs.uiuc.edu<br>Message-ID: <1322102768428-3532706.post@n3.nabble.com><br>Content-Type: text/plain; charset=us-ascii<br><br>Hi all,<br><br>I just started learning clang example. I tried to build an example (as<br>attached .cpp and Makefile), and get the following link errors:<br><br>/nfs/susangao/llvm-root/my-example/clang/tut/test.cpp:30: undefined<br>reference to `clang::CompilerInstance::CompilerInsta<br>http://clang-developers.42468.n3.nabble.com/file/n3532706/test.tar.gz<br>test.tar.gz nce()'<br>/nfs/susangao/llvm-root/my-example/clang/tut/test.cpp:33: undefined<br>reference to `clang::CompilerInstance::createDiagnostics(int, char const*<br>const*, clang::DiagnosticConsumer*, bool, bool)'<br>/nfs/susangao/llvm-root/my-example/clang/tut/test.cpp:35: undefined<br>reference to<br>`clang::CompilerInvocation::CreateFromArgs(clang::CompilerInvocation&, char<br>const* const*, char const* const*, clang::DiagnosticsEngine&)'<br>/nfs/susangao/llvm-root/my-example/clang/tut/test.cpp:37: undefined<br>reference to `clang::TargetInfo::CreateTargetInfo(clang::DiagnosticsEngine&,<br>clang::TargetOptions&)'<br>/nfs/susangao/llvm-root/my-example/clang/tut/test.cpp:37: undefined<br>reference to `clang::CompilerInstance::setTarget(clang::TargetInfo*)'<br>/nfs/susangao/llvm-root/my-example/clang/tut/test.cpp:39: undefined<br>reference to `clang::CompilerInstance::createFileManager()'<br>/nfs/susangao/llvm-root/my-example/clang/tut/test.cpp:40: undefined<br>reference to<br>`clang::CompilerInstance::createSourceManager(clang::FileManager&)'<br>/nfs/susangao/llvm-root/my-example/clang/tut/test.cpp:41: undefined<br>reference to `clang::CompilerInstance::createPreprocessor()'<br>/nfs/susangao/llvm-root/my-example/clang/tut/test.cpp:42: undefined<br>reference to `clang::CompilerInstance::createASTContext()'<br>/nfs/susangao/llvm-root/my-example/clang/tut/test.cpp:43: undefined<br>reference to `clang::CompilerInstance::setASTConsumer(clang::ASTConsumer*)'<br>/nfs/susangao/llvm-root/my-example/clang/tut/test.cpp:45: undefined<br>reference to<br>`clang::CompilerInstance::createSema(clang::TranslationUnitKind,<br>clang::CodeCompleteConsumer*)'<br>/nfs/susangao/llvm-root/my-example/clang/tut/test.cpp:47: undefined<br>reference to<br>`clang::CompilerInstance::InitializeSourceManager(llvm::StringRef)'<br>/nfs/susangao/llvm-root/my-example/clang/tut/test.cpp:48: undefined<br>reference to `clang::ParseAST(clang::Preprocessor&, clang::ASTConsumer*,<br>clang::ASTContext&, bool, clang::TranslationUnitKind,<br>clang::CodeCompleteConsumer*)'<br>/nfs/susangao/llvm-root/my-example/clang/tut/test.cpp:50: undefined<br>reference to `clang::CompilerInstance::~CompilerInstance()'<br>/tmp/ccqBn324.o: In function `ASTConsumer':<br>/nfs/susangao/llvm-root/llvm/tools/clang/include/clang/AST/ASTConsumer.h:39:<br>undefined reference to `vtable for clang::ASTConsumer'<br>/tmp/ccqBn324.o: In function `~ASTConsumer':<br>/nfs/susangao/llvm-root/llvm/tools/clang/include/clang/AST/ASTConsumer.h:41:<br>undefined reference to `vtable for clang::ASTConsumer'<br>/tmp/ccqBn324.o: In function<br>`llvm::raw_ostream::operator<<(llvm::StringRef)':<br>/nfs/susangao/llvm-root/llvm/include/llvm/Support/raw_ostream.h:160:<br>undefined reference to `llvm::raw_ostream::write(char const*, unsigned<br>long)'<br>/tmp/ccqBn324.o: In function<br>`llvm::raw_ostream::operator<<(std::basic_string<char,<br>std::char_traits<char>, std::allocator<char> > const&)':<br>/nfs/susangao/llvm-root/llvm/include/llvm/Support/raw_ostream.h:176:<br>undefined reference to `llvm::raw_ostream::write(char const*, unsigned<br>long)'<br>/tmp/ccqBn324.o: In function `clang::NamedDecl::getNameAsString() const':<br>/nfs/susangao/llvm-root/llvm/tools/clang/include/clang/AST/Decl.h:135:<br>undefined reference to `clang::DeclarationName::getAsString() const'<br>/tmp/ccqBn324.o: In function<br>`PrintFunctionsConsumer::HandleTopLevelDecl(clang::DeclGroupRef)':<br>/nfs/susangao/llvm-root/my-example/clang/tut/test.cpp:21: undefined<br>reference to `llvm::errs()'<br>/tmp/ccqBn324.o:(.data.rel.ro._ZTV22PrintFunctionsConsumer[vtable for<br>PrintFunctionsConsumer]+0x30): undefined reference to<br>`clang::ASTConsumer::HandleInterestingDecl(clang::DeclGroupRef)'<br>/tmp/ccqBn324.o:(.data.rel.ro._ZTV22PrintFunctionsConsumer[vtable for<br>PrintFunctionsConsumer]+0x48): undefined reference to<br>`clang::ASTConsumer::HandleTopLevelDeclInObjCContainer(clang::DeclGroupRef)'<br>collect2: ld returned 1 exit status<br>make: *** [all] Error 1<br><br><br>Would you please help me to know what causes this link error?<br><br>The code of llvm and clang are checked out from trunk.<br><br>APPRECIATE!<br><br>Susan<br><br><br>--<br>View this message in context: http://clang-developers.42468.n3.nabble.com/New-comer-s-problem-library-link-error-of-a-clang-example-tp3532706p3532706.html<br>Sent from the Clang Developers mailing list archive at Nabble.com.<br><br><br>------------------------------<br><br>_______________________________________________<br>cfe-dev mailing list<br>cfe-dev@cs.uiuc.edu<br>http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev<br><br><br>End of cfe-dev Digest, Vol 53, Issue 89<br>***************************************<br></div></blockquote></div><br></div></body></html>