Date: Mon, 30 Nov 2020 17:56:37 +0100 From: Michal Meloun <meloun.michal@gmail.com> To: Ian Lepore <ian@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r368187 - head/sys/dev/nvme Message-ID: <b32dcdee-52ea-8eed-4dde-1f9f7990a54f@freebsd.org> In-Reply-To: <5bd6eb969c3a198246ab915257375b02c7b14e0c.camel@freebsd.org> References: <202011301451.0AUEpn9w002536@repo.freebsd.org> <5bd6eb969c3a198246ab915257375b02c7b14e0c.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 30.11.2020 17:02, Ian Lepore wrote: > On Mon, 2020-11-30 at 14:51 +0000, Michal Meloun wrote: >> Author: mmel >> Date: Mon Nov 30 14:51:48 2020 >> New Revision: 368187 >> URL: https://svnweb.freebsd.org/changeset/base/368187 >> >> Log: >> Unbreak r368167 in userland. Decorate unused arguments. >> >> Reported by: kp, tuexen, jenkins, and many others >> MFC with: r368167 >> >> Modified: >> head/sys/dev/nvme/nvme.h >> >> Modified: head/sys/dev/nvme/nvme.h >> ===================================================================== >> ========= >> --- head/sys/dev/nvme/nvme.h Mon Nov 30 14:49:13 2020 (r368186) >> +++ head/sys/dev/nvme/nvme.h Mon Nov 30 14:51:48 2020 (r368187) >> @@ -1728,9 +1728,15 @@ extern int nvme_use_nvd; >> >> #endif /* _KERNEL */ >> >> +#if _BYTE_ORDER != _LITTLE_ENDIAN >> +#define MODIF >> +#else >> +#define MODIF __unused >> +#endif >> + >> /* Endianess conversion functions for NVMe structs */ >> static inline >> -void nvme_completion_swapbytes(struct nvme_completion *s) >> +void nvme_completion_swapbytes(struct nvme_completion *s MODIF) > > IMO, this is pretty ugly, it causes the brain to screech to a halt when > you see it. Why not just add an unconditional __unused to the > functions? The unused attribute is defined as marking the variable as > "potentially unused" -- there is no penalty for having it there and > then actually using the variable. > I understand, (and I have significant tendency to agree) but I did not find more correct way how to do it. Are you sure that __unused is defined as *potentially* unused? I cannot find nothing about this and you known how are compiler guys creative with generating of new warnings... I known that C++17 have 'maybe_unused' attribute, but relationship to standard '__unused' looks unclear. In any case, I have not single problem to change this to the proposed style if we found that this is the optimal way. Michal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b32dcdee-52ea-8eed-4dde-1f9f7990a54f>