From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) by sourceware.org (Postfix) with ESMTPS id BE94C3854142 for ; Mon, 4 Jul 2022 16:40:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BE94C3854142 Received: by mail-io1-xd33.google.com with SMTP id p69so9047695iod.10 for ; Mon, 04 Jul 2022 09:40:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=95DtIbj/1fRpSQzSsAu3uDrAJRoz/OZkDD0SCbUKMag=; b=THVIZptG6XKKGMq+WPeZz9lCMp9lAp+vX4yhD0MKla2B8Wyt59g/JDLAHKrQex+N27 83L6fbNoJTvmltdr7J0MOoybYJ0g2OqLIydQEGePKM0wCBf8daLrXtBDheKynP/Hs/Ku +Z0V+6/8qDO5OPs+b+FAEXVQx2ZTRd/eCcmLVwYdFuvBvMFgOARPVWUSYMV2SGPeJC1J vytEXk+aDtxBU0TBDHCOJ4B3FOLO5Ql8md6x7qOQbKy5pFbskBLUFZ5nn7N+fdQzJ3dK DyHC0hC2sWfWKiHqR2wCdewxVFMQbIjT+R+VDi+/70AX17TSDb9iR85b3e5ON/F6j5WF er/w== X-Gm-Message-State: AJIora8vwfb9AdA9fZhCn64H395khSErdhfQ8zPbwTP8f0oktGu/YUSh EbC8b2lbjSdtrFYXHniHD4xnkMNk0Ds= X-Google-Smtp-Source: AGRyM1vMkqBZcG9LvntgEUmT7My+1il31ZMi/wSmyp6xtqDiyBST7yBmRTquL92uiPGFEV6jAKHNZg== X-Received: by 2002:a05:6638:1507:b0:33d:7bd:9479 with SMTP id b7-20020a056638150700b0033d07bd9479mr16178805jat.34.1656952856519; Mon, 04 Jul 2022 09:40:56 -0700 (PDT) Received: from [192.168.0.23] (65-130-94-229.slkc.qwest.net. [65.130.94.229]) by smtp.gmail.com with ESMTPSA id k14-20020a0566022a4e00b0067821726c8csm4526636iov.53.2022.07.04.09.40.55 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Jul 2022 09:40:56 -0700 (PDT) Message-ID: <6f8778b6-0665-5096-6044-fb94e5003220@gmail.com> Date: Mon, 4 Jul 2022 10:40:53 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH] [12/11/10] Fix invalid format warnings on Windows Content-Language: en-US To: gcc-patches@gcc.gnu.org References: <466c29c3-54b1-5627-3d9d-e385ad037a4e@suse.cz> <7fd8d3fb-e0c6-decc-374f-495ab81ab1ff@gmail.com> <8f515605-4fc0-148d-3011-a79f672ea025@suse.cz> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2022 16:40:59 -0000 On 5/16/2022 5:27 AM, Tomas Kalibera via Gcc-patches wrote: > > On 5/11/22 18:43, Joseph Myers wrote: >> There are various coding style issues in the patch; at least missing >> space >> before '(' and '&&' at end of line (should be at start of line).  It >> will >> also need to be updated for .c files having been renamed to .cc in >> the GCC >> source tree. > > Thanks, I've fixed the formatting issue and updated the patch for > master, 12, 11 and 10. In addition to the renaming of .c to .cc files, > there was also a change in the first argument of > check_function_format. I've also removed a duplicated check for > whether fndecl was null and fixed indentation. > > I've updated the patches for each version to also note that in > > c51f1e7427e6a5ae2a6d82b5a790df77a3adc99a > gcc: Add `ll` and `L` length modifiers for `ms_printf` > > the ms_printf format has been taught to support (not warn about) > printing the 64-bit integers using the "%ll" modifier (currently GCC > 11 and newer). However, I assume there may be other differences > between the ms_printf and gnu_printf formats people might run into, so > it still makes sense to fix this not only in GCC 10, but also in newer > versions. > > Furthermore, the attached patch is still needed (GCC 11, GCC 12, > master) to get rid of duplicate warnings for an incorrect format (e.g. > "%lu" used to print "unsigned long long"), when both ms_printf and > gnu_printf formats are violated (PR 92292). I guess we're going to depend on the builtin-format always appearing first in the chain?  While it's probably true in practice, I doubt we really want to depend on that. Is there any sensible way to distinguish between the builtin format and one that comes from the source? There's a trivial formatting nit: > + for(aa = TREE_CHAIN (a); aa; aa = TREE_CHAIN (aa)) Space between the "for" and its open paren. But I think the big question here is whether or not we want to assume the builtin format is always first on the chain. jeff