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=-1.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, 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 BBD141F4B8 for ; Tue, 30 Apr 2024 00:31:52 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=BM+I3w6G; dkim-atps=neutral Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s1bP6-00047F-Sx; Mon, 29 Apr 2024 20:31:28 -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 1s1bP1-00046t-RD for bug-gnulib@gnu.org; Mon, 29 Apr 2024 20:31:26 -0400 Received: from mail-pf1-x42d.google.com ([2607:f8b0:4864:20::42d]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s1bOx-0008Qt-Rn for bug-gnulib@gnu.org; Mon, 29 Apr 2024 20:31:22 -0400 Received: by mail-pf1-x42d.google.com with SMTP id d2e1a72fcca58-6ed112c64beso4830027b3a.1 for ; Mon, 29 Apr 2024 17:31:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714437071; x=1715041871; darn=gnu.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=fWZRx+khIeLslhZhjCqnRwaPGEBvzYI6ZSIkMyQNuTQ=; b=BM+I3w6GMFrhcHd0bt/MaUrNJ97nLJc31N36sazxDdkD1pJRAmzs6o/tnOxo9GoWYc UN4khIzHkIaNHlxw4CRilwVLRFJMazwEGDEcNfoMt8cKbjHeXML3ooiE4Rg+k/RLHokg +zb049gveAlkNC6cvHbi3PB3rWfmivQtKn2D19LCoc7n4gdH+3rJC7WHWiHTmKlCVi6f tiYNFmwPTFYGk07U3TD/lemv+XDlXQTa74ER/7yecCBNAE0ZoGTIvR0Ekc1qiAWYjNz1 5bv7uG6s9se+JNuNdTOjX6Wk2volOvcW9NsElB0qWNuxBLzq4aQI6MGD+TqujgPdMJx4 2S5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714437071; x=1715041871; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=fWZRx+khIeLslhZhjCqnRwaPGEBvzYI6ZSIkMyQNuTQ=; b=Uh5NfFy9oKcOEMh9h8h/D6ZXErc5/DNEgcGuEoCgDCQLKraV4VZvbRybtV0guTbYJ0 Vm72uPxpx2IWxFxmxYc/mqDSTL/8RWANvZZNmgUX6n44fSDQeFnZKuyM4998/F24Olrz P+iv+4WDgXzZwe0a6TGhMqlgGgAPcCxeTgl50gGaNJEROQi6xwWzt4G0C7nHmid6vL4X 8MAKhFDbJ/jgNWOxWRdPrOBU48tkjwRod7aGCQuKNlvAsExCl3LM4b2trMHr+qVQpBcD eBTj0mPfNY/QlCuK+dve2xl7dFVX1jwS5qT7ULz91ySxfDYzYvrrg+2GBGpnlKyKBMZ2 1wNA== X-Forwarded-Encrypted: i=1; AJvYcCUjLo2X5lInxcS4ZhShj5q2M4wdynbabKy8c3HT1E7WeQVPJWgb96lGTvtRJoltwnfkn4EtzHI0NueJI/2mT/nh+gQ= X-Gm-Message-State: AOJu0Yz4v13liUW86Nn8MG4O8ULHDbwF27+WwDYm36Wnq+X6RtweFpiY fjxDYfnFiU8REF8VxdSdCe3ah+zU79JIhtcq0HHR8ydL1EE5HrUX X-Google-Smtp-Source: AGHT+IFKxLevILjldFuQfOmMzKMHYWKeM/H61JQFjTIixeBKCY5Xd7yPwE5AlD/+zZi66Zky+I/yQQ== X-Received: by 2002:a05:6a21:6704:b0:1af:4e95:ff3b with SMTP id wh4-20020a056a21670400b001af4e95ff3bmr4375861pzb.39.1714437071277; Mon, 29 Apr 2024 17:31:11 -0700 (PDT) Received: from [192.168.1.11] (c-73-189-213-139.hsd1.ca.comcast.net. [73.189.213.139]) by smtp.gmail.com with ESMTPSA id x6-20020a170902820600b001e43df03096sm20948836pln.30.2024.04.29.17.31.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 29 Apr 2024 17:31:10 -0700 (PDT) Message-ID: <736e5958-018a-43ea-bd69-8da9fc7cb76f@gmail.com> Date: Mon, 29 Apr 2024 17:31:09 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: warnings in unit tests To: Bruno Haible , Paul Eggert , bug-gnulib@gnu.org References: <10c966f9-34aa-40fd-8659-6075098b0006@gmail.com> <7804088.cEBGB3zze1@nimes> Content-Language: en-US From: Collin Funk In-Reply-To: <7804088.cEBGB3zze1@nimes> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=2607:f8b0:4864:20::42d; envelope-from=collin.funk1@gmail.com; helo=mail-pf1-x42d.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Bruno, On 4/29/24 3:12 PM, Bruno Haible wrote: > Note that different warning policies may contradict each other. For example, > some people want to see a warning for > > int *table = malloc (n * sizeof (int)); > > because it has an implicit conversion / "lacks a cast". While other people > want to see a warning for > > int *table = (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. Yes, I've seen both in gnulib. I'm pretty sure the cast is required for C++ (though I think gcc has a warning to make it less strict). Maybe a 5th category is code taken from another GNU program. Or 4.5th category since there are only a few glibc files and mini-gmp IIRC. In that case the original developer and their preferences would have to be respected of course. :) > 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_ — as Paul wrote — 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. That makes sense to me. Thanks for the explanation. > 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. Ah, thanks for the tip. That sounds quicker than modifying the Makefiles by hand. Collin