Date: Tue, 05 Jun 2018 21:00:49 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Ian Lepore <ian@freebsd.org> Cc: Eric van Gyzen <vangyzen@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r334669 - head/sys/sys Message-ID: <33373.1528232449@critter.freebsd.dk> In-Reply-To: <1528232004.63685.25.camel@freebsd.org> References: <201806052034.w55KYBsb096418@repo.freebsd.org> <1528232004.63685.25.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
-------- In message <1528232004.63685.25.camel@freebsd.org>, Ian Lepore writes: >On Tue, 2018-06-05 at 20:34 +0000, Eric van Gyzen wrote: >> (((flags) & M_WAITOK) || _malloc_item != NULL) > >This is a sad sad thing. Treating (bits & flagconstants) as boolean has >a long long history in C. Surely there are literally thousand of >occurrances in freebsd code already, so why did this one get flagged? FlexeLint also gets its knickers in a twist about this kind of construct and as far as I can tell the origin of that particular interpretation comes out of the MISRA C rules. In FlexeLint that specific check can be disabled, and I would imagine Coverity has a similar tweakable setting. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?33373.1528232449>