Re: [PATCH 01/61] Coccinelle: Prefer IS_ERR_OR_NULL over manual NULL check
Markus Elfring <[email protected]>
| Newsgroups | dev.linux.lists.ntfs3,dev.linux.lists.dm-devel,dev.linux.lists.gfs2,dev.linux.lists.iommu,dev.linux.lists.sched-ext,dev.linux.lists.v9fs,fr.inria.cocci,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