Is there a way to configure which types of problems the XCode 4 static Analyzer tool reports and doesn't report?
I'm am dealing with some legacy code that "works" but has tons of static analysis issues, and am trying to list certain potentially more critical issues first.
I don't have a lot of experience customizing Clang (the static analyzer Xcode uses) myself, but this blog post seems to point to two different change you can make:
Turning off some individual warning types in the Build Settings
Using pragma to ignore specific warnings once you're aware of the right argument
While these options don't really provide any method of "prioritizing" the warnings, you can at least temporarily ignore the ones that you know to be less critical.
In Xcode 4, under project or target Build Settings, near the bottom, are the settings for the Apple LLVM compiler x.0 - Warnings and Static Analyzer - Checkers. In those build settings, one can turn off or on various warnings that the Product Analyze menu generates, such as report Dead Stores, etc.
Related
I wanted to check if any warning showing in my project for implicit BOOL conversions at compile time where I can fix for Apple Silicon support. Apple mentioned in below document for enabling the compiler option -Wobjc-signed-char-bool-implicit-int-conversion to see those warnings. Can you help me where I can enable this option? I don't find such option in project settings or scheme settings.
https://developer.apple.com/documentation/apple_silicon/addressing_architectural_differences_in_your_macos_code
You can do this per target, but also for the whole project. The targets inherit from the project but can be customised as well. Anyhow, select your project (the top node in the tree view) and then select Build Settings.
Now you will see something like this if you scroll down and search enough. You can either set it as a custom flag (similar to the -Wno-unused-getter-return-value in the image) or you can set it if it is available as one of the Warnings just below the custom flags, it seems to be the Implicit Boolean Conversions warning.
You can achieve this via build settings as stated by skaak.
If you would prefer pragma declarations you can define:
#pragma clang diagnostic error "-Wobjc-signed-char-bool-implicit-int-conversion"
I am copying JSTileMap and LFCGzipUtility into the project and when I run the application it generates several warnings for both files.
However, when I run the provided sample from github, I don't see any of those warnings.
I would like to know why is there a difference, and in case, what am I doing wrong?
For reference please visit, https://github.com/slycrel/JSTileMap
Clarification, I would like to know if there is anything I should change in the project settings, rather than debug the code that runs just fine and without any warnings on the provided sample at the links above.
if you are running your app in the iOS simulator 64 bit mode then the problem is that the files of JSTileMap are not updated to 64 bit architecture
Apple documents says
Code that relies on the NSInteger and CGFloat types needs to be carefully examined.
Start by building the app for the 64-bit runtime, fixing any warnings that occur as well as searching your code for specific 64-bit issues. For example:
Make sure all function calls have a proper prototype.
Avoid truncating 64-bit values by accidentally assigning them to a 32-bit data type.
Ensure that calculations are performed correctly in the 64-bit version of your app.
Create data structures whose layouts are identical in the 32-bit and 64-bit versions of your app (such as when you write a data file to iCloud).
here is the Apple's transition guide to 64 bit:
https://developer.apple.com/library/ios/documentation/General/Conceptual/CocoaTouch64BitGuide/Introduction/Introduction.html
if that is not your case the open the file JSTileMap.m, inside press command + f type warning and press enter
and you will find all the warnings that JSTileMap want you to see just comment all warning and thats it
Here i show you all the warnings
#warning these appear to be incorrect for iso maps when used for tile objects! Unsure why the math is different between objects and regular tiles.
#warning This needs to be optimized into tilemap layers like our regular layers above for performance reasons.
#warning the positioning is off here, seems to be bottom-left instead of top-left.
#warning need to write setTileGidAt:
Good Luck!!
I know that I can ignore compiler warnings with -w on a given file in Xcode.
I would like to similarly ignore analyze warnings on a given file (JSONKit.m in this case, which has two potential leaks). I trust that the developer of that library knows what they're doing, and I don't want to maintain a fork of it. Not to mention that I have no clue what's going on in there anyway.
Any ideas?
Don't trust the developer. Figure out why the potential leaks exist and fix them (ideally, sending a patch back to the developer).
If you want to take the lazy way out (j/k ;), you can add code to fix the problem under the analyzer only using:
#ifdef __clang_analyzer__
... release the offending variable here ...
#endif
I prefer this solution to whole-file-disabling because it both exactly identifies the problem area with an easily searchable identifier and it allows the rest of the file to be vetted by the constantly improving analyzer.
I am working on a legacy project that has a large amount of files dating back to pre-OS X days. It's data has been 16 bit aligned for > 15 years. I would like to move to a full LLVM compilation but I can't seem to get 2 byte alignment working. Are there any compiler level options available for this? (previously using -malign-mac68k)
I am aware of the #pragma pack(2) option here. However that would require me to modify upwards of 1000 source files to include this. That it's a worst-case option, but it seems like a hack. Besides, if this is possible then surely there is a default option to set the alignment?
According to clang's sources, it does support mac68k alignment rules. It seems that right now you can enable it via "#pragma options align=mac68k" only. If you're ok with small clang hacking, then you can implement the cmdline option as well and submit the patch to clang.
I would suggest looking at #pragma pack (see http://msdn.microsoft.com/en-us/library/2e70t5y1%28v=vs.80%29.aspx and http://gcc.gnu.org/onlinedocs/gcc/Structure_002dPacking-Pragmas.html). It's relatively easy to use, and should work with any compiler Apple ships.
i use the latest gcc/gortran on osx compiled by the guys at ibm, if you read the gcc manual there are at least 8 different alignment optimizations to consider not just the bulk malign
Because system-level headers assume default alignment (they don't have directives to override alignment in most cases), changing the alignment for everything will break OS calls. As such, you don't want to be doing this.
Just write a script to apply your #pragma pack(2) to the source files in question, avoiding #includes. It's relatively easy and unlikely to cause unfortunate side-effects.
I am having a CI setup with incremental build. As part of the static checking, I am planning to configure a incremental PC Lint report - This report ignoring all other previous Lint report should provide the errors induced in the new code only. Is there any tool which would do this?
Any hint on the relative area to explore would help us.
I tried report diff'ing. But since the line number would vary from last check-in, would not get the actual incremental error introduced.
I am using Linux for my project build, and using Windows for PC Lint report generation.
Regards,
Wouldn't it be easier to just fix all the reported errors, and have a strict policy against creating new ones? That way you don't need to worry about diffs which by the nature of the problem is going to be hard to impossible.
You could write a script that takes the warnings from lint, removes the line numbers and adds a few lines from the source code around where the warning occurs. Diffing this would show all new lint warnings. One flaw in this, is that it would also show any warnings where source was modified near an existing warning without fixing the warning. On the other hand, this might actually be useful.
Years ago, I saw a utility on BDS Unix that would take your compiler errors and stuff them into your source code as comments. Which might be useful for this exercise. Unfortunately I can't remember what it was called.