andrew.w.kaylor added a comment. The LLVM linker also seems to have a bunch of problems with resolving pointer types in structures. I'm looking into a couple of those now.
I am aware of the opaque pointer effort, though as you say it seems to be stalled. I agree that there aren't a lot of things you can do based on pointer type information, but there are some things that you might like to do which can be proven to be unsafe based on pointer type information that might be incorrectly flagged as unsafe if the pointer type information is incorrect. An example would be the sorts of data layout optimizations described here: https://llvm.org/devmtg/2014-10/Slides/Prashanth-DLO.pdf Note, in particular, on slide 11 ("Legality") the reference to "cast to/from a given struct type". I would imagine that includes pointer casts. It should be possible to do the same sort of analysis with opaque pointers by following their uses very carefully, and maybe not having these infernal pointer type casts all over the place would make that less prone to false negatives. In the meantime, the pointer casts are there and have to be dealt with. Getting back to the current review, Erich explained to me that this patch involves a certain amount of risk in that it changes the way clang processes things, but it has the merit of getting the correct answer. https://reviews.llvm.org/D49403 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
