From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pb-smtp1.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 219FC14A09E for ; Thu, 29 Aug 2024 18:06:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=64.147.108.70 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724954788; cv=none; b=AdjcqGLzkgd6G5Jpxl9HEbLkceo9DMYnfcUSfGXXtquDIBnZHre+5g2GVpocUriKaV8WeZqHSUnFUd0t51+2NCU9T1DtljKQ/5QvBnlSyR7EQ6r1FXc0ylwdz7naWV7R7KrgPOHp8a5dzyMPm2e641QOZI7sifhy6lzIj8RfG2A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724954788; c=relaxed/simple; bh=hmnTkAAHqhrJ+WPpj4F5xmR7h39on3oRfk3bK9f+kMg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=oYGMhmFuDp+BOLT3HCzQpTTso7HghOJSf8+nb8peZefT4RNAk/z40n6MhKzyoUMLutN7H/keAVjS8f4oieAzf/k3EfVACZrRwArhE0onxXHsJJZypmnYJgy6I7G1Z70nf+Wt6kBzTGuQq0iDEqXJsJkqdlVTiCmXHLjasnAzZKQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=pobox.com; spf=pass smtp.mailfrom=pobox.com; dkim=pass (1024-bit key) header.d=pobox.com header.i=@pobox.com header.b=b8NgXgAT; arc=none smtp.client-ip=64.147.108.70 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=pobox.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pobox.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=pobox.com header.i=@pobox.com header.b="b8NgXgAT" Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id E5B7824113; Thu, 29 Aug 2024 14:06:23 -0400 (EDT) (envelope-from gitster@pobox.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h=from:to:cc :subject:in-reply-to:references:date:message-id:mime-version :content-type; s=sasl; bh=hmnTkAAHqhrJ+WPpj4F5xmR7h39on3oRfk3bK9 f+kMg=; b=b8NgXgATzbdz5gjp+Nt7H7tPUCzsmhBrUhcd+qYXSt0UBvHVB2r/kJ X0Ugnu83i8tQ5IJteYb71OfRSU2s4vIZurWt+73+cWmZgH16JxKHRFLPFhPv4rQY 0qdLAhs1ZKkuq4QMAqtTK0+9cCcmdTs0sXuI3rQqaWWqdoOu5sZz0= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id DE89824112; Thu, 29 Aug 2024 14:06:23 -0400 (EDT) (envelope-from gitster@pobox.com) Received: from pobox.com (unknown [34.125.94.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 559CF24111; Thu, 29 Aug 2024 14:06:23 -0400 (EDT) (envelope-from gitster@pobox.com) From: Junio C Hamano To: Jeff King Cc: git@vger.kernel.org Subject: Re: [PATCH 8/6] CodingGuidelines: also mention MAYBE_UNUSED In-Reply-To: <20240829175215.GA415423@coredump.intra.peff.net> (Jeff King's message of "Thu, 29 Aug 2024 13:52:15 -0400") References: <20240829040215.GA4054823@coredump.intra.peff.net> <20240829175215.GA415423@coredump.intra.peff.net> Date: Thu, 29 Aug 2024 11:06:22 -0700 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: git@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: 66AA4468-6631-11EF-85B2-2BAEEB2EC81B-77302942!pb-smtp1.pobox.com Jeff King writes: >> +/* >> + * MAYBE_UNUSED marks a function parameter that may be unused, but >> + * whose use is not an error. >> + * >> + * Depending on a configuration, all uses of a function parameter may >> + * become #ifdef'ed away. Marking such a parameter with UNUSED would >> + * give a warning in a compilation where the parameter is indeed used, >> + * and not marking such a parameter would give a warning in a >> + * compilation where the parameter is unused. >> + */ >> #define MAYBE_UNUSED __attribute__((__unused__)) > > This is all good as pertains to function parameters. But the original > reason we added MAYBE_UNUSED was actually for static functions that were > auto-generated by the commit-slab macros. Saying "...marks a function > parameter" implies to me that it's the only use. I don't know if we want > to be more expansive here or not. Adding auto-generated macro functions > should be quite a rarity, I'd think. True. You can annotate types, variables, and functions with the attributes as well. How about saying something like this MAYBE_UNUSED marks a function parameter that may be unused but whose use is not an error. It also can be applied to functions, types and variables. and then keep the explanation of why you may want to use the maybe- variant as-is, using a function parameter as an example? Or I could rewrite "parameter" and "function parameter" in it with "thing" (with double quotes around), like: Depending on a configuration, all uses of a "thing" may become #ifdef'ed away.... Unlike the use of deprecated attribute, our definition of MAYBE_UNUSED is not guarded with anything. Shouldn't we at least do #if defined(__GNUC__) #define MAYBE_UNUSED __attribute__((__unused__)) #else #define MAYBE_UNUSED /* noop */ #endif or something, by the way? Thanks.