From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id 7E81E1F4B4 for ; Tue, 13 Apr 2021 21:07:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344552AbhDMVHf (ORCPT ); Tue, 13 Apr 2021 17:07:35 -0400 Received: from pb-smtp1.pobox.com ([64.147.108.70]:61412 "EHLO pb-smtp1.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229610AbhDMVHe (ORCPT ); Tue, 13 Apr 2021 17:07:34 -0400 Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 34E40B5F07; Tue, 13 Apr 2021 17:07:14 -0400 (EDT) (envelope-from junio@pobox.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=ULIz9MoZa0C50FRtryUa4zP5aCs=; b=D2HB7m nk28iB1mwNJsaogGpWx9zPcaRQveAGK2a+FHDyZIvh95PVx7yWsMACtdXxb1lMfr B3Sv5tulNKakY/86FN1bzkdY4cZSXXX4eEyWuyDURzu+NSDOTpEM9zX11BOOOd0F 1RYA2oZtK6BoMk1m1AVnHuI1vJvqgxGv7FiNM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=uzqQKVU7tVU8bQeEfU9ApelopkpFlQOO rF/Laga5GrPa+4+hcg00UBmgr3nty318d/Er5OlwJrt7fvdpSLr6UiqPUselcds8 ZsUZ/pZ5G2TmntcMZORptESyKvGvSu+TqePxXA9WegUhP1xhzyODhfwhw/Or41A9 ma/5nUb2NTE= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 2D923B5F04; Tue, 13 Apr 2021 17:07:14 -0400 (EDT) (envelope-from junio@pobox.com) Received: from pobox.com (unknown [34.74.119.39]) (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 A9F42B5F03; Tue, 13 Apr 2021 17:07:13 -0400 (EDT) (envelope-from junio@pobox.com) From: Junio C Hamano To: Jeff King Cc: =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason , git@vger.kernel.org, "brian m . carlson" Subject: Re: [PATCH 1/2] git-compat-util.h: clarify comment on GCC-specific code References: Date: Tue, 13 Apr 2021 14:07:13 -0700 In-Reply-To: (Jeff King's message of "Tue, 13 Apr 2021 03:57:52 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: 383AB656-9C9C-11EB-83D2-D152C8D8090B-77302942!pb-smtp1.pobox.com Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Jeff King writes: >> + * We restrict this trick to gcc, though, because while we rely on the >> + * presence of C99 variadic macros, this code also relies on the >> + * non-standard behavior of GCC's __VA_ARGS__, allowing error() to >> + * work even if no format specifiers are passed to error(). The last part of this comment is puzzlling. Do we ever call error() without any format specifier? There may be GCC-ism behaviour around the __VA_ARGS__ stuff, but are we relying on that GCC-ism? >> + * Since we're only trying to help gcc, anyway, it's OK; other >> + * compilers will fall back to using the function as usual. >> */ >> #if defined(__GNUC__) > > I don't mind leaving this gcc-only, since as you note that's the point > of what the code is trying to do. But wouldn't this always work because > we know there is at least one arg (the format itself)? > > I.e., if we had written: > > #define error(fmt, ...) (error(fmt, __VA_ARGS__), const_error()) > > that would be a problem for: > > error("foo"); > > But because we wrote: > > #define error(...) (error(__VA_ARGS__), const_error()) > > then it's OK. I think so. At least I find the new comment confusing, and I'd prefer to see it cleaned up. Thanks.