Re: [PATCH 01/61] Coccinelle: Prefer IS_ERR_OR_NULL over manual NULL check
From: Markus Elfring <hidden>
Date: 2026-03-11 15:12:55
Also in:
amd-gfx, bpf, ceph-devel, cocci, dm-devel, dri-devel, gfs2, intel-gfx, intel-wired-lan, kvm, linux-block, linux-bluetooth, linux-btrfs, linux-cifs, linux-clk, linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv, linux-input, linux-iommu, linux-leds, linux-media, linux-mips, linux-mm, linux-modules, linux-nfs, linux-omap, linux-phy, linux-pm, linux-rockchip, linux-s390, linux-scsi, linux-sctp, linux-security-module, linux-sh, linux-sound, linux-trace-kernel, linux-usb, linux-wireless, lkml, netdev, sched-ext, target-devel, v9fs
…
+// 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