rule: intfromptr-compare-with-zero

[190n]

Description

This rule would forbid comparing the result of @intFromPtr(...) with zero, unless the pointer is allowzero (allowzero pointers are rare enough that, if type analysis isn't able to determine pointer annotations, it might be acceptable if you need to manually disable this rule for @intFromPtr calls on allowzero pointers).

For pointers that are neither optional nor allowzero, @intFromPtr will never return zero because such pointers are forbidden from being zero. Optimization knows this and makes a comparison with zero always return false. So this comparison is always a bug.

For optional, non-allowzero pointers, @intFromPtr(p) != 0 does have the intended behavior, but I think it's cleaner to write p != null which is why I'm proposing this rule apply to those pointers too.

Examples

Examples of incorrect code for this rule

pub const Header = struct {
    name: []const u8,
    pub fn isMultiline(self: Header) bool {
        // oops, always false
        return @intFromPtr(self.name.ptr) == 0;
    }
};

pub const Example = struct {
    optional_data: ?*u32,
    pub fn hasData(self: Example) bool {
        // works, but comparison with null is nicer
        return @intFromPtr(self.optional_data) != 0;
    }
};

Examples of correct code for this rule

pub const Header = struct {
    name: []const u8,
    pub fn isMultiline(self: Header) bool {
        return self.name.len == 0;
    }
};

pub const Example = struct {
    optional_data: ?*u32,
    pub fn hasData(self: Example) bool {
        return self.optional_data != null;
    }
};

// for this example suppose you're writing an OS or something
pub const MemoryMapping = struct {
    pages: []allowzero align(4096) const u8,
    pub fn isStartOfAddressSpace(self: MemoryMapping) bool {
        // this code is correct and there's not a better way to express it
        return @intFromPtr(self.pages.ptr) == 0;
    }
};