From owner-svn-src-all@freebsd.org Mon Nov 30 17:43:33 2020 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A12934A3916 for ; Mon, 30 Nov 2020 17:43:33 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2k.ore.mailhop.org (outbound2k.ore.mailhop.org [54.148.219.64]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ClCJP2NlWz4SCJ for ; Mon, 30 Nov 2020 17:43:33 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1606758212; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=cuHlZQ0mLIZG8Xo6W74sKmtkkuoKqCcleXOXoC+J7UaIQkdLLPbjt8Ng9cGOBt7/tSq+qosVeojWE 2u88CB6ucy0QaxWm59foyQGnB7jk1aX56GZtvMGK7Zm2VULb1KDqUkF09Uty1Z4r1xSONKimygRMXO qO/mQYLDY14zwiv4MfxWqzu7ejCmSeyxDuebJHWON5i90eL852z3OFE1oWY6/9E3c7dfNz9J8H8FvY 3hPFudUAKFFZKwVaAydVbmt+1OZJu3SKKCwU85BWUTq0hUUrSHhRewHL48cfRnXk4kJJJcOGvMnRhg P97AjXAUqlTDePj7jZbE0OiES9XL08A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=8hx53+qKgYigHLB57pMRUmV2L+BjzcrLuNThcZcWBn4=; b=lbOkNbzwYAIh7yJn66WiTMkK4ZhOZXtmo6ya19NT8LYZurxgB2M6OIm2pLk+0xSLI4IZ//s/GnJ/I jizlgMXIns1hx/lknOyMiUovbLzgjcDh4bcoCJaiQ+4sGP5LFmzFxRWWuYzUoSmxdMt+Tdq8p3wjp7 YQ6VElXWrQqlFIqtYFHHPIIPE6k1rn4pJ7Zwx4qtyZmF2H8AMyjxMtgRYUxacNwuMfJdyzjgMng7YV pwqGyaitEqBrk1XtBmhdxduspLwR812SJOq5LWCieZYZ7OdxKQ1HtGkyKHmpSyQlLBO3/yOpzoKmeN 2YAcM+9QGdYcc9578XpNZvaBhm22wQw== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=8hx53+qKgYigHLB57pMRUmV2L+BjzcrLuNThcZcWBn4=; b=hfLvgOT7UsuwGADfOAdUtoNWmWC0IQPh8zsm2zP7BnvseXDx1+3SMO1BF2hsXn5pVzFHfeIpQMsMI R1JrEVNRtSlW0aNcFRb1LDqJlwjcPlBVdeU8SbI8JsgwIJrlGvylEbWjsJoO/sAnZisx3iQcaes2gt M39T+Rwz1NnuI129OG5o2TlXsMBs+OTM0C7EjnKYo0jBQ1ECDgRNvMXUe14SjikA2qNs8cmdsYjxdu O2CeO4wDQ3nuNFsuW18gIdb/LUsrH83OcWOHJiEazwy92PciwzjidBbt6xUGgOecsDTaM3O4P2DCG0 JNXTFhqzMgEnbn7fYWukaDsVsNvdZOA== X-MHO-RoutePath: aGlwcGll X-MHO-User: 8e901499-3333-11eb-9e13-df46ed8f892f X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 8e901499-3333-11eb-9e13-df46ed8f892f; Mon, 30 Nov 2020 17:43:30 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 0AUHhSZk091321; Mon, 30 Nov 2020 10:43:28 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <53cedfd91e07e2cfc4b2f77ff0795c1d5cf68707.camel@freebsd.org> Subject: Re: svn commit: r368187 - head/sys/dev/nvme From: Ian Lepore To: mmel@freebsd.org, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Mon, 30 Nov 2020 10:43:28 -0700 In-Reply-To: References: <202011301451.0AUEpn9w002536@repo.freebsd.org> <5bd6eb969c3a198246ab915257375b02c7b14e0c.camel@freebsd.org> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4ClCJP2NlWz4SCJ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2020 17:43:33 -0000 On Mon, 2020-11-30 at 17:56 +0100, Michal Meloun wrote: > > 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 The __unused macro is defined in cdefs.h under #if __GNUC_PREREQ__(2, 7) as attribute((unused)) and the gcc docs for that attribute say "This attribute, attached to a [variable|function], means that the variable is meant to be possibly unused. GCC will not produce a warning for this variable." -- Ian