[cfe-dev] usage of clang in an university project

[Nuno Lopes]

>> Thank you for your fast answer.
>> Today I was reading the clang code and I'm now trying to implement  an 
>> ASTConsumer, as I'll have to do a little more analysis that just 
>> checking function calls. I also need to know when a particular  variable 
>> used in the function call is initialized or not as well as  if it is not 
>> initialized by the function call (through a pointer)  whether it is used 
>> afterwards or not. I still didn't know if this  will be simple enough to 
>> do, but I'll try..
>
> Ok, the dataflow framework Ted is working on will be useful to you.   We 
> don't really support interprocedural analysis yet though.

No, I don't need interprocedural analysis right now. For now, I'll just code 
what the functions do. e.g.:
zend_parse_parameters(ZEND_NUM_ARGS(), "s|d", &str, &str_len, &integer);

I know that str and str_len will get initialized (unless the function 
returns FAILURE) and that integer may or may not be initialized. So for now, 
I'll have all the information hard-coded. Maybe next year I can do my master 
thesis with clang/llvm and use interprocedural analysis.


>> For now, I have just more two questions:
>> - is it possible to disable clang warnings and output just the  warnings 
>> I'll be generating? (I added a -parse-ast-sirs opt for me)
>
> Yes.  The Diagnostic class handles mapping of warnings and other 
> diagnostics to error levels.
>
> Just call Diagnostics->setDiagnosticMapping(somediag,  diag::MAP_IGNORE); 
> to ignore somediag.

OK, thanks, I'll check it out.


>> - can clang ignore parsing errors? e.g. if it can't find an  header.h 
>> file can it continue even if a function is called without  being 
>> declared.
>
> No, not in full generality.  In C you need information about types to  be 
> able to parse, for example.

It could just ignore type checking and such kind of checks, as I don't need 
that. It is enough for me to have the function/type names without further 
information.
Do you think I can workaround this? It's very very important for this 
particular project.


>> This is especially useful in my case because I'll be parsing the  PHP 
>> sources (in C) and I don't have all the external libraries that  some PHP 
>> extensions rely on, but I still would like to be able to  analyse those 
>> extensions, though.
>
> You may have some luck, but in general it won't work well.

damn..


>> BTW, in attach you'll find a backtrace I got when doing executing 
>>  'clang -parse-ast-*'. It happens when I parse a PHP source file and 
>> when not all include (-I) paths are specified. I took a quick look  at 
>> those functions, but I couldn't fix the bug myself.
>
> Please create a .i file with clang and send that in:  clang  whatever.c -E 
>  > output.i

Attached.


Thanks,
Nuno 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: php_pcre.c.clang.i
Type: application/octet-stream
Size: 28612 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20071007/a1396941/attachment.obj>