Clang Static Analyzer - Extending - clang-static-analyzer

I am new to using Clang and wanted to understand if it was possible to extend the existing functionality of the static code analyzer. Basically for now I want to add a check that will analyze code and look for certain calls to see file system access in objective c code. I want it to integrate and output the findings into the existing static analysis report that Clang produces. Is this something that can be done in Clang? I know there are easier ways to do it by writing scripts (python,etc.) to parse the source code, but I want to see if this can be done with the existing Clang stuff. I did see the libClang library that might be able to accomplish this, but it seems that will not integrate into the static analysis findings report and is different.
Any help is appreciated.

Related

how to remove a data source from rrd db programatically?

I'm trying to remove a data source from a rrd db.
I found I can do something like
"rrdtool tune mydb.rrd DEL:source_name"
and it works, but I want to do it from C/C++ code.
I could use the system function in Linux, but I don't
like the overhead.
I looked in https://oss.oetiker.ch/rrdtool/doc/librrd.en.html
to see if there is something I could use, but I didn't find anything.
I also looked in the rrd source code from https://github.com/oetiker/rrdtool-1.x/tree/master/src
and I found they call rrd_modify_r2() to remove sources, but this function is static, so it's not exported (as opposed to rrdc_create_r2)
So, how can I remove a source from C/C++ code ?
thanks,
Catalin
You use of course rrdtool tune filename.rrd DEL:ds-name to do this from the commandline, as you note.
However the RRDTool C bindings in librrd are not as comprehensive, and do not appear to expose this functionality. Not sure why - the modify functions is clearly useful - but thats how it seems to be.
One option you have would be to simply call the external rrdtool binary with fork/exec, passing the appropriate commandline. This is not a particularly pretty way to do it, but is more portable and compatible with the published interface.

NSIS - Compile with opcode re arranged to prevent access to source code

I am trying to reduce and make as difficult as possible the ability to access my source code after being compiled by NSIS. I have read that the only way to reduce the chance of unzipping is to modify the order of the opcodes in the Source\fileform.h from the source code and then Compile the new version.
This is a bit over my head. I was wondering if anyone has done this before and willing to post one they have done. (Or create one for me?)
Main reason for this is I have info that I encrypt using blow-fish within NSIS and do not want the chance oFf someone finding out what the encryption keys are. (Used for licencing the software) I understand noting is fool proof, but just want it as difficult as possible.
I know its asking a lot, but could really this.
Thanks!
I don't believe there are any publicly available modified builds like that. And if there were and it got popular, the decompilers would just add support for it.
I have a complete step-by-step guide to building NSIS here.
If you know C/C++, Delphi or C# you could build your own private NSIS plug-in that handles the encryption details.
No matter what you do, somebody who knows how to use a debugger can easily set a breakpoint on the blow-fish plug-in and view your key. The only way around that is a custom plug-in or an external application that handles the cryptography internally...

Customising Cabal libraries (I think?)

Perhaps it's just better to describe my problem.
I'm developing a Haskell library. But part of the library is written in C, and another part actually in raw LLVM. To actually get GHC to spit out the code I want I have to follow this process:
Run ghc -emit-llvm on both the code that uses the Haskell module and the "Main" module.
Run clang -emit-llvm on the C file
Now I've got three .ll files from above. I add the part of the library I've handwritten in raw LLVM and llvm-link these into one .ll file.
I then run LLVM's opt on the linked file.
Lastly, I feed the LLVM bitcode fileback into GHC (which pleasantly accepts it) and produces an executable.
This process (with appropriate optimisation settings of course) seems to be the only way I can inline code from C, removing the function call overhead. Since many of these C functions are very small this is significant.
Anyway, I want to be able to distribute the library and for users to be able to use it as painlessly as possible, whilst still gaining the optimisations from the process above. I understand it's going to be a bit more of a pain than an ordinary library (for example, you're forced to compile via LLVM) but as painlessly as possible is what I'm looking for advice for.
Any guidance will be appreciated, I don't expect a step by step answer because I think it will be complex, but just some ideas would be helpful.

template instantiation statistics from compilers

Is there a way to get a summary of the instantiated templates (with what types and how many times - like a histogram) within a translation unit or for the whole project (shared object/executable)?
If I have a large codebase and I want to take advantage of the C++11 extern keyword I would like to know which templates are most used within my project (or from the internals of stl - like std::less<MyString> for example).
Also is it possible to have a weight assigned to each template instantiation (time spent by the compiler)?
Even if only one (c++11 enabled) compiler gives me such statistics I would be happy.
How difficult would it be to implement such a thing with Clang's LibTooling?
And is this even reasonable? Many people told me that I can reason which template instantiations I should extern without the use of a tool...
There are several ways to attack this problem.
If you are working with an open-source compiler, it's not hard to make a simple change to the source code that will trace all template substantiations.
If that sounds like too much hassle, you can also try to force the compiler to produce a warning on each template instantiation for a given symbol. Steven Watanabe has written a set of tools that can help you with that.
Finally, possibly the best options is to use the debugging symbols (or map files), generated by the compiler, to track down how many times each function appears in the final image and more importantly how much does it add to the weight in bytes. The best example for such a tool is Andrian Stone's SymbolSort, which is based on the Microsoft's toolset. Another similar tool is the Map File Browser.

adding extra codes at runtime in java

I am developing a library and I need to add extra codes to some of my methods of my objects at run time. there are two points here. first of all, the program I wanted to add extra code, is written before by some body else, and I don't wanted to edit it. second, my work is very similar to adding aspect before calling a method.
After searching and reading on in internet, I found out many frameworks like aspectj, ASPECTWERKZ and etc. that could do this job, but for example the problem with aspectj(when using in spring context) is that it doesn't provide you any API to do your weaving at runtime.
I also found out there are some libraries like ASM and javassist and etc. but they are so general and hard to learn, and my job is more likely to aspects.
So what do you suggest? is there any good library out there? Am I wrong about above libraries i mentioned earlier? Please Help!
With AspectJ you can apply your aspects when classes are loaded at runtime. See Load-Time Weaving documentation. Alternatively, you don't have to change your old code and can apply aspects at compile time.

Resources