Re: [cocci] [PATCH 01/61] Coccinelle: Prefer IS_ERR_OR_NULL over manual NULL check

Markus Elfring <[email protected]> Wed, 11 Mar 2026 16:12:34 +0100
Newsgroups fr.inria.cocci,dev.linux.lists.dm-devel,dev.linux.lists.gfs2,dev.linux.lists.iommu,dev.linux.lists.ntfs3,dev.linux.lists.sched-ext,dev.linux.lists.v9fs,org.freedesktop.lists.amd-gfx,org.freedesktop.lists.dri-devel,org.freedesktop.lists.intel-gfx,org.infradead.lists.linux-mtd,org.infradead.lists.linux-phy,org.infradead.lists.linux-rockchip,org.kernel.vger.bpf,org.kernel.vger.ceph-devel,org.kernel.vger.kvm,org.kernel.vger.linux-block,org.kernel.vger.linux-bluetooth,org.kernel.vger.linux-btrfs,org.kernel.vger.linux-cifs,org.kernel.vger.linux-clk,org.kernel.vger.linux-ext4,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-gpio,org.kernel.vger.linux-hyperv,org.kernel.vger.linux-input,org.kernel.vger.linux-kernel,org.kernel.vger.linux-leds,org.kernel.vger.linux-media,org.kernel.vger.linux-mips,org.kernel.vger.linux-modules,org.kernel.vger.linux-nfs,org.kernel.vger.linux-omap,org.kernel.vger.linux-pm,org.kernel.vger.linux-s390,org.kernel.vger.linux-scsi,org.kernel.vger.linux-sctp,org.kernel.vger.linux-security-module,org.kernel.vger.linux-sh,org.kernel.vger.linux-sound,org.kernel.vger.linux-trace-kernel,org.kernel.vger.linux-usb,org.kernel.vger.linux-wireless,org.kernel.vger.netdev,org.kernel.vger.target-devel,org.kvack.linux-mm,org.osuosl.intel-wired-lan,org.ozlabs.lists.linux-erofs
Message-ID <[email protected]> 
…
> +// Confidence: High

Some contributors presented discerning comments for this change approach.
Thus I became also curious how much they can eventually be taken better into account
by the means of the semantic patch language (Coccinelle software).

…
+@p1 depends on patch@
+expression E;
+@@
+(
> +-	E != NULL && !IS_ERR(E)
> ++	!IS_ERR_OR_NULL(E)
> +|
> +-	E == NULL || IS_ERR(E)
> ++	IS_ERR_OR_NULL(E)
> +|
> +-	!IS_ERR(E) && E != NULL
> ++	!IS_ERR_OR_NULL(E)
> +|
> +-	IS_ERR(E) || E == NULL
> ++	IS_ERR_OR_NULL(E)
> +)

Several detected expressions should refer to return values from function calls.
https://en.wikipedia.org/wiki/Return_statement

* Do any development challenges hinder still the determination of corresponding
  failure predicates?

* How will interests evolve to improve data processing any further for such
  use cases?


Regards,
Markus