From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on starla X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_PASS, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 438A31F4B8 for ; Mon, 29 Apr 2024 22:12:35 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=clisp.org header.i=@clisp.org header.a=rsa-sha256 header.s=strato-dkim-0002 header.b=jUiUCSq7; dkim=fail reason="signature verification failed" header.d=clisp.org header.i=@clisp.org header.a=ed25519-sha256 header.s=strato-dkim-0003 header.b=jEPl3bQy; dkim-atps=neutral Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s1ZEQ-0005OI-Cd; Mon, 29 Apr 2024 18:12:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s1ZEL-0005O5-Ah for bug-gnulib@gnu.org; Mon, 29 Apr 2024 18:12:14 -0400 Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.216]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s1ZEJ-00023X-8j for bug-gnulib@gnu.org; Mon, 29 Apr 2024 18:12:13 -0400 ARC-Seal: i=1; a=rsa-sha256; t=1714428726; cv=none; d=strato.com; s=strato-dkim-0002; b=MocgczJ2xQ/CfmrVHWBAPP5cnC7AR8VRcaLARKqaIoj+aZgnfMH9nOpgWsuCZbzWvI O2EuBc6z1Jcwd8KIilp/fgqJ1n5OhqWfMmlW4UCzF8CEJU8kx5UQLQ+bhrGTcbeQ+NR4 uP0PeyOUYK+ptBr9dWTt58/HFKWbT0DkA6TVUexy03hqp8jJSSIjQSfDHuGnBx9QVow/ dKz4/vs4btfP8AB1TsOLYRb/rOL75eUpTX6MyCBaP1T4TrmdDrF2HI2f+CQzVxhXJel1 ucaXdXtuCvx9P3TMQ4WiOkDQYNZpIYC/56/dStOuAzVbyOVy8qSp13+1IitqDgiv2D+x N73Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1714428726; s=strato-dkim-0002; d=strato.com; h=References:In-Reply-To:Message-ID:Date:Subject:To:From:Cc:Date:From: Subject:Sender; bh=Vb0EDUqaPoP87jFQ9VUOZg0kiGvZziK1exjUOjH9QgA=; b=WLCvaafQx5KGqLSVRqKOh4h72MmIcxJI4k9qJwndNmSrQCN4ywAEWXvWlljwOGekoO UMbYzUVxylT2ar2kFDwCSkTiq4aFO//zuHLzhFjivNQ7zJRzlN+6UL9oj6TlHUOaLK9U ndkmg2xRMOzWniuh0EG3AtbCDuN/bvA4DNi0/Lxus6cdM3DYhzpdCE5WPNHVHREYsbIf IBI4l+cv4UvhSysaDCZrqwRM7S1GSGLyVGXOz31O3NxNUYzwKKzoNzoG5z2frvX3WoFY e2bWrCpRGrVoEte82JRLNJCee5vZ7I/pXbH8gKUb1uYiGkL8wE2ipS7R0Ew6C6cEeT8b F45w== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1714428726; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:To:From:Cc:Date:From: Subject:Sender; bh=Vb0EDUqaPoP87jFQ9VUOZg0kiGvZziK1exjUOjH9QgA=; b=jUiUCSq7IZP8JvuydTBBAPYfoRMXlDL7PgiqymzOGmOzSLWItcx7scvuwXl7ByWzd+ JBq6b0zsySGeyT9vEPdbQHlb1W2+9mmHhw7v8EmVDwZ7JwmfO1iokP4qd8tgEAMGPV03 BGBLQJeuvJ73shEVX5acjBgovQxw9AUG9gYAbLwNx2RnxgCYVJDvEmcXNKCdRV2ZprI5 dlYXT6Kg6glfZ6k2Z+g4wiSFxor47R3LnbvTEncsa4AF11rYrtXnZdbYwFqPRHKULqGy Tf9+Q0nnt4KftujPfhOWv3xgwQOlGSEVOisEGVGKZEiVfcycP1hPButz7NoQNOB1jbDp O3HA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1714428726; s=strato-dkim-0003; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:To:From:Cc:Date:From: Subject:Sender; bh=Vb0EDUqaPoP87jFQ9VUOZg0kiGvZziK1exjUOjH9QgA=; b=jEPl3bQy0G54N5uLSRUgNUtcIu4gvzNIDAYNMHG9jySs3GmIMN5HNgGoiN8W5ORYq2 jmsYwzyjGsgMEEI1boAg== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH0WWb0LN8XZoH94zq68+3cfpPAj/NIqLPyg2EXH7fjVXqjqPuHZw==" Received: from nimes.localnet by smtp.strato.de (RZmta 50.5.0 AUTH) with ESMTPSA id Ndd2ca03TMC5Qqq (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Tue, 30 Apr 2024 00:12:05 +0200 (CEST) From: Bruno Haible To: Paul Eggert , bug-gnulib@gnu.org, Collin Funk Subject: Re: warnings in unit tests Date: Tue, 30 Apr 2024 00:12:05 +0200 Message-ID: <7804088.cEBGB3zze1@nimes> In-Reply-To: <10c966f9-34aa-40fd-8659-6075098b0006@gmail.com> References: <10c966f9-34aa-40fd-8659-6075098b0006@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Received-SPF: none client-ip=81.169.146.216; envelope-from=bruno@clisp.org; helo=mo4-p00-ob.smtp.rzone.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Hi Collin, > > For test cases this is more a judgment call, but I prefer doing either > > the above or adjusting the warning flags, to ignoring warnings, as the > > other warnings can be useful at time. >=20 > Yeah, I could see these warnings making it hard to see ones that > actually matter. Lets see what Bruno thinks. Different warning policies need to apply in these fours sets code: 1) Code that originates in the package that uses gnulib. Example: coreutils/src/* 2) Code from public header files in gnulib/lib/ Example: lib/vasnprintf.h because module 'vasnprintf' designates this fi= le as its public header file. 3) All other code from gnulib/lib/ Example: lib/argp-namefrob.h which is not a public header file, lib/*.c. 4) All code in gnulib/tests/ Note that different warning policies may contradict each other. For example, some people want to see a warning for int *table =3D malloc (n * sizeof (int)); because it has an implicit conversion / "lacks a cast". While other people want to see a warning for int *table =3D (int *) malloc (n * sizeof (int)); because it has a cast and "casts are dubious". It is impossible to satisfy both of these policies at the same time. Back to the four sets of code: 1) This warning policy is the responsibility of that package's maintainer, obviously. 2) These header files are used in compilation units of the package, with CFLAGS or AM_CFLAGS set by the package's maintainer for that package. Therefore in these files we need to avoid even -Wundef, -Wvla, and other kinds of warnings that we wouldn't enable in our code. 3) The rest of the lib/ code is under our responsibility, not the responsibility of a package's maintainer. We try to avoid warnings from "reasonable" warning options. More details in the HACKING file. 4) The unit tests are also in our responsibility, not the responsibility of a package's maintainer. Here, the primary concern is that is must be *easy* to contribute new unit tests. -Wmissing-variable-declarations warnings _could_ =E2=80=94 as Paul wrote =E2=80=94 be avoided by adding = an 'extern' declaration for each global variable. But this is extra effort that would hinder the addition of new unit tests. > If we decide to follow the coding style you mentioned No. It must be possible to contribute a unit test with a simple global variable. Therefore -Wmissing-variable-declarations is not adequate for unit tests. Collin, if you want to find relevant findings in the unit tests, by using gcc or clang warning options, do *not* use a coreutils build for this purpose, but a gnulib testdir instead. (Because the latter is not biased by coding style preferences of any package maintainer.) Or if you really want to use a coreutils build, first update the GL_CFLAG_GNULIB_WARNINGS definition in m4/gnulib-common.m4, so that it eliminates useless kinds of warnings. Bruno