INFO: SonarQube Scanner 3.3.0.1492
build-wrapper, version 6.1 (macosx-x86)
We have an issue where variables set in the constructor (init) are being flagged with “An integral type is too small to hold a pointer value”. but the argument that is passed in, and the instance variable, are in fact the same type. We have 10 issues 8 of which seem to be this (others are downcasts of non-pointers into smaller integers). We just started using SonarQube so there is no baseline to compare this to unfortunately.
Also worth noting, it doesn’t seem to happen in self.*, and it doesn’t seem to happen with built-in classes like NSError. Maybe there is some missing information for the compilation?
thank you for your report, in order to help me reproduce the issue, could you tell me what type is VTMessageFilter or VTCheckAccountStatus? To see if I can quickly create a reproducer for it, thank you.
Perhaps I should wait to see if there is a configuration issue, but there are 2 other false-positive sources that I have found.
(inherited legacy code) when a switch contains goto statements they are incorrectly interpreted as switch cases, for a repro you could build https://github.com/boredzo/iso-8601-date-formatter/blob/master/ISO8601DateFormatter.m and should see errors of:
Move the label referenced by this goto statement outside its current block (valid’ish, it’s not good code but it is jumping out of a switch/if, so cognitively difficult to trace but not unclear)
Remove this misleading “parseWeekAndDay” label. (false positive)
Possible optimizer modifications might be resulting in empty methods and “Add a nested comment explaining why this method is empty, or complete the implementation”? This appears in a base class that doesn’t appear to have any direct references (but might be called automagically by the XML parser), we see a lot of them in the classes that derive from that base class also. We also have some encodeWithCoder classes that appear to be used (the initWithCoder and encodeWithCoder are both used), but the encodeWithCoder is marked as empty. It seems like most of the “critical” issues found are this false positive (561/664).
There is also a singular issue that appears to be SonarScanner assuming that a variable is in fact a function (maybe hardcoded name “read”?). This error occurs both on the encode and decode sides, but only for “read” (not for 10+ other variables)
these errors might be linked to the fact that some header files are not found.
For instance, the false positive about empty function body is due to error recovery, which means that VTActiveSyncNamespace is probably not found, in any case for this I create a ticket: CPP-2191.
Could you please share privately build-wrapper-dump.json and sonar-scanner verbose log? I am sending you a private message for sharing.
I found quite a big one, we are currently not supporting Xcode 10 pch files, in Xcode 10 the default file suffix for pch generation was changed and we missed it, if in your sonar-scanner output you get many error logged regarding pch file not found, CPP-2192 is going to fix your problem. Release of the analyzer is scheduled for next week.
NFO: SonarScanner 4.5.0.2216
build-wrapper, version 6.15 (macosx-x86)
Xcode Version 12.3 (12C33)
We still have the same issue: a lot of false positives with the “An integral type is too small to hold a pointer value” error. It seems that during the analyze phase it does not include other than public headers or system frameworks.
#import "SENTLocationMediator.h"
@interface SENTLocationMediator ()
@property (nonatomic, assign) CLAuthorizationStatus lastLocationAuthorizationStatus;
@end
@implementation SENTLocationMediator
- (instancetype)init {
self = [super init];
if (self) {
[self initialiseLocationManager];
}
return self;
}
- (void)initialiseLocationManager {
...
// This is the problem line
self.lastLocationAuthorizationStatus = [self locationAuthorizationStatus];
...
}
- (CLAuthorizationStatus)locationAuthorizationStatus {
return [CLLocationManager authorizationStatus];
}
