I just found an insidious and disconcerting characteristic of the uVision3 ARM compiler V3.12a. I have inherited C code to migrate to the ARM processor. This C code uses unsigned char pointers quite liberally to pass the address of data back and forth. The code, of course, casts these generic unsigned char pointers to various data types to access the underlying data. I have found that if the unsigned char point happens to be pointing at a odd address and it is cast to a short type pointer (e.g., "*(SHORT*)p"), the compiler will resolve the address the previous even address. For a simplistic example, if the address of unsigned char *p happens to be 0x5 and the following code is executed:
unsigned char *p; ... *(unsigned short*)p = 0;
Running lint on the project code would provide some measure of just how bad the code is and could be used as the basis for choosing between fix and rewrite.
From http://www.gimpel.com/html/reviews.htm ... "ALOA (short for A Lint Output Analyzer) is a tool that processes output generated by PC-lint and computes various useful metrics that give a quick overview of the internal quality of any C/C++ project. Furthermore, it shows which kind of Lint issues are most frequently encountered and highlights issue-laden modules. The metrics produced by ALOA are useful for tracking a project's lint compliance and for fine-tuning Lint policies."