Abstraction
I am Zhengyang, a M.S. candidate at Beijing University of Posts and Telecomunications working in the area of static program analysis. My CV can be found in [2]. Most of my works are based on Clang Static Analyzer. I have contributed to Static Analysis Suite (SAS) from CERN PH-SFT as Google Summer of Code 2015 project. About the preparation for this proposal, I have studied several research papers of compiler time transform and runtime program hardening techniques. I am interested in working with LLVM community, and hoping to contribute to this summer with LLVM.
You sound super cool 
I’m curious, what kind of static analysis stuff are you into?
Also: Can you give examples of the kinds of bugs you’re looking for? I’d like to make sure were not duplicating effort.
It should be “Baggy” and not “Beggy.” Also, I prefer “BBC” over “Baggy,” but that is just my personal preference. First, you should clearly state that a prototype version of BBAC is already implemented in the SAFECode compiler, and you should explain which types of run-time checks it already performs. You should also clearly state which types of errors you plan to detect within the GSoC time frame. For example, if you are going to implement explicit checks for dangling pointers, you should describe exactly how you plan to implement those checks (e.g., what metadata is required, when that metadata will be created and updated, and how run-time checks will use it). Cite sources as needed. Storing points-to set information in the metadata will allow you to detect casting errors and some dangling pointer errors, but it will not catch all. If you have a dangling pointer to one memory object and it points to another memory object in the same set due to a dangling pointer error, your approach will not detect the error. You should not assume that the reader knows what “guarded_by” means. You should briefly describe it and cite a source (preferably a peer-reviewed paper if possible). Please keep in mind that your proposal will be reviewed by people other than the potential mentor (in other words, I won’t be the only person reviewing your proposal). You should make sure that your proposal is comprehensible to them. This already exists. You can add as much padding as you want, so it’s not clear to me why this is needed. Which benchmarks do you plan to use? This should really be done as part of GSoC. Your proposal should, ideally, provide a rough sketch of the design so that it isn’t being worked on during GSoC. Which points-to analysis will you be using? Making this into a research paper would be great! I recommend attaching a full-fledged CV or resume with your proposal instead of providing a link (though a link will do if there is no other way to attach a CV/resume). You want to give the reviewers as little work to do as possible when reviewing your application. Regards, John Criswell