| Message ID | 20191128080631.117-1-lstipakov@gmail.com |
|---|---|
| State | Superseded |
| Headers |
Return-Path: <openvpn-devel-bounces@lists.sourceforge.net> Delivered-To: patchwork@openvpn.net Delivered-To: patchwork@openvpn.net Received: from director7.mail.ord1d.rsapps.net ([172.28.255.1]) by backend30.mail.ord1d.rsapps.net with LMTP id OF9oN1uA310fOgAAIUCqbw for <patchwork@openvpn.net>; Thu, 28 Nov 2019 03:07:55 -0500 Received: from proxy9.mail.ord1c.rsapps.net ([172.28.255.1]) by director7.mail.ord1d.rsapps.net with LMTP id aFJUN1uA311oeAAAovjBpQ ; Thu, 28 Nov 2019 03:07:55 -0500 Received: from smtp26.gate.ord1c ([172.28.255.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by proxy9.mail.ord1c.rsapps.net with LMTP id iHkcN1uA3133aAAAgxtkuw ; Thu, 28 Nov 2019 03:07:55 -0500 X-Spam-Threshold: 95 X-Spam-Score: 0 X-Spam-Flag: NO X-Virus-Scanned: OK X-Orig-To: openvpnslackdevel@openvpn.net X-Originating-Ip: [216.105.38.7] Authentication-Results: smtp26.gate.ord1c.rsapps.net; iprev=pass policy.iprev="216.105.38.7"; spf=pass smtp.mailfrom="openvpn-devel-bounces@lists.sourceforge.net" smtp.helo="lists.sourceforge.net"; dkim=fail (signature verification failed) header.d=sourceforge.net; dkim=fail (signature verification failed) header.d=sf.net; dkim=fail (signature verification failed) header.d=gmail.com; dmarc=fail (p=none; dis=none) header.from=gmail.com X-Suspicious-Flag: YES X-Classification-ID: 2e77eade-11b6-11ea-85a0-b8ca3a5bd12c-1-1 Received: from [216.105.38.7] ([216.105.38.7:46766] helo=lists.sourceforge.net) by smtp26.gate.ord1c.rsapps.net (envelope-from <openvpn-devel-bounces@lists.sourceforge.net>) (ecelerity 4.2.38.62370 r(:)) with ESMTPS (cipher=DHE-RSA-AES256-GCM-SHA384) id 13/5A-18213-B508FDD5; Thu, 28 Nov 2019 03:07:55 -0500 Received: from [127.0.0.1] (helo=sfs-ml-2.v29.lw.sourceforge.com) by sfs-ml-2.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from <openvpn-devel-bounces@lists.sourceforge.net>) id 1iaEpB-0003ir-27; Thu, 28 Nov 2019 08:06:53 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-2.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from <lstipakov@gmail.com>) id 1iaEpA-0003ik-4a for openvpn-devel@lists.sourceforge.net; Thu, 28 Nov 2019 08:06:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=NOItIXkZHCjDgZjLV3WZJ6Z9ay8DV285Pvy4WuPDLx8=; b=hISturznDHwxvZ+PPtMIifRt+2 LebB+z0afHMWL45vpGYLjA+DQoq4CTu/LjneT1ro16B3SP62gP+jc30nZp9FGjpIFPLsLN7nJFGD0 aUyfyO3OqwTHW37boYJCxy4F8UNI9bXvwo2SAj3+RjEaPnygRY7ocgpdT0os1+2qjZFU=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=NOItIXkZHCjDgZjLV3WZJ6Z9ay8DV285Pvy4WuPDLx8=; b=nSw+ObvckYnUvwUX+B7HP/d+XP M1FjMU9AR/vP+wePgqRkj853E30Dvt8SzLVfTSMMtXAmZ3oU7Dkm8yTUv8qd9W1w9x4qJ9Kum7ja6 ISK9499tGxhRp3ilp0xIHm9YUtek94twekbtAKuCtnj4/rj5W1S2YFyMNIwH0GHBPKbc=; Received: from mail-wm1-f67.google.com ([209.85.128.67]) by sfi-mx-4.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.2) id 1iaEp6-00FzvH-Ft for openvpn-devel@lists.sourceforge.net; Thu, 28 Nov 2019 08:06:52 +0000 Received: by mail-wm1-f67.google.com with SMTP id f129so10616158wmf.2 for <openvpn-devel@lists.sourceforge.net>; Thu, 28 Nov 2019 00:06:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=NOItIXkZHCjDgZjLV3WZJ6Z9ay8DV285Pvy4WuPDLx8=; b=uB7AePGN4kQCgTEVvGFdq2vQx9PT2/l8MjnJKsF57JemqzTMZ/d2LJxpy/Y22e/zkb P3P8D8Xa4OoS6AKzmjZChF3gVfP7zmlB+cHfp0NGgH8/grTLVRyclMKDDrV2BtdkZfHw Xh5a0ahLhqBAXWqWC/vJ9IT4az00nRGdbkdjoQw0HO/kjjeh+TCKH5pKW+8EboiFydmZ 8Zd60YWkxVSzrl8patcceBzQbiL9d/T5TuCajmv0B9nXJlaAvi9UjrVAg8lHBdKhDoRb wWYTQg1QMd6nUIKoiUelgwI679gSxio+/r1el5gMVhi04PLtmjDuI4VXabpsXdwUVAzQ D5dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=NOItIXkZHCjDgZjLV3WZJ6Z9ay8DV285Pvy4WuPDLx8=; b=l9gZ9q9CiyGWGssXSegr3j8vn/+PQsyS7ew7SE+XbxFExRaxgAoOnJrC1HxDJEh8L6 w1vro8t/pMcHte1ZZd1K3tNqNMnGM6x+hXwRLxjFduxZyqtoie1zPgloW+KiXjX56UOK uviS3G8o1ILyhQO6JosFz9NtpVQk6NH0MyQnwiyKQzLIHIjESWaOH6f9u3EnHNPF8yUG bguJwbRn9lM8DFBmOaqPXe5qmkUstbJHP3ATM3BwajMZrHjIg+5JjK4S5SfALfN8zM2u sb4oOADr2XAziTrkv0XYLWWyJd66PBSALjfBvRG956O73+jikgztMk3yZgz/amhEVyU7 tMLw== X-Gm-Message-State: APjAAAWd1Tw6g+wNPOyx9riEyry3q9UiCzWkaq6dhRT7a1p2wNiNK7wT 7FaWeqDAXZ2ODxGOn1iuWSJVxHj5N9E= X-Google-Smtp-Source: APXvYqxZdfTNYHUEy76x3gIoAj+j9hSXixqrwMryQvDJqbEgj3HOluNLxuRu0+pCUm1LY7QBzRxTjQ== X-Received: by 2002:a7b:ca57:: with SMTP id m23mr8068548wml.65.1574928401382; Thu, 28 Nov 2019 00:06:41 -0800 (PST) Received: from LAPTOP-4L3N7KFS.panoulu.local ([2a00:1d50:3:0:123:e072:8fa4:4f76]) by smtp.gmail.com with ESMTPSA id i71sm24632972wri.68.2019.11.28.00.06.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Nov 2019 00:06:40 -0800 (PST) From: Lev Stipakov <lstipakov@gmail.com> To: openvpn-devel@lists.sourceforge.net Date: Thu, 28 Nov 2019 10:06:31 +0200 Message-Id: <20191128080631.117-1-lstipakov@gmail.com> X-Mailer: git-send-email 2.17.1 X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: openvpn.net] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (lstipakov[at]gmail.com) -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.128.67 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.128.67 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid X-Headers-End: 1iaEp6-00FzvH-Ft Subject: [Openvpn-devel] [PATCH] fix clang warning about missing braces X-BeenThere: openvpn-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: <openvpn-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/options/openvpn-devel>, <mailto:openvpn-devel-request@lists.sourceforge.net?subject=unsubscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=openvpn-devel> List-Post: <mailto:openvpn-devel@lists.sourceforge.net> List-Help: <mailto:openvpn-devel-request@lists.sourceforge.net?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/openvpn-devel>, <mailto:openvpn-devel-request@lists.sourceforge.net?subject=subscribe> Cc: Lev Stipakov <lev@openvpn.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: openvpn-devel-bounces@lists.sourceforge.net X-getmail-retrieved-from-mailbox: Inbox |
| Series |
[Openvpn-devel] fix clang warning about missing braces
|
|
Commit Message
Lev Stipakov
Nov. 27, 2019, 9:06 p.m. UTC
From: Lev Stipakov <lev@openvpn.net> A struct with subobjects should be initialized with double braces. Signed-off-by: Lev Stipakov <lev@openvpn.net> --- src/openvpn/crypto.c | 2 +- src/openvpn/crypto_mbedtls.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
Comments
On 28-11-2019 09:06, Lev Stipakov wrote: > A struct with subobjects should be initialized > with double braces. This is not true. {0} is a valid initializer for structs in C. Both clang and gcc used to have a bug where they incorrectly warned about this. GCC fixed this a while ago[0]. I thought clang had fixed it too recently, but apparently not? -Steffan [0] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119
Hi On Thu, Nov 28, 2019 at 10:23 AM Steffan Karger < steffan.karger@foxcrypto.com> wrote: > On 28-11-2019 09:06, Lev Stipakov wrote: > > A struct with subobjects should be initialized > > with double braces. > > This is not true. {0} is a valid initializer for structs in C. Both > clang and gcc used to have a bug where they incorrectly warned about > this. GCC fixed this a while ago[0]. I thought clang had fixed it too > recently, but apparently not? > Pretty much same as my thoughts. I think the correct fix here is to remove -Werror from travis build. I have tried and failed to lobby for this earlier, but one more try can't hurt, I suppose :) That said, it seems clang has fixed this some time after clang-7. I don't get this warning anymore after upgrading to clang-9. Selva <div dir="ltr"><div>Hi<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 28, 2019 at 10:23 AM Steffan Karger <<a href="mailto:steffan.karger@foxcrypto.com" target="_blank">steffan.karger@foxcrypto.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 28-11-2019 09:06, Lev Stipakov wrote:<br> > A struct with subobjects should be initialized<br> > with double braces.<br> <br> This is not true. {0} is a valid initializer for structs in C. Both<br> clang and gcc used to have a bug where they incorrectly warned about<br> this. GCC fixed this a while ago[0]. I thought clang had fixed it too<br> recently, but apparently not?<br></blockquote></div><div class="gmail_quote"><br></div><div class="gmail_quote">Pretty much same as my thoughts.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><div>I think the correct fix here is to remove -Werror from travis build.</div><div>I have tried and failed to lobby for this earlier, but one more try</div><div>can't hurt, I suppose :)</div><div><br></div><div>That said, it seems clang has fixed this some time after clang-7.</div><div>I don't get this warning anymore after upgrading to clang-9.<br></div><div><br></div><div>Selva<br></div></div></div>
hi, On Thu, Nov 28, 2019 at 11:56:34AM -0500, Selva Nair wrote: > I think the correct fix here is to remove -Werror from travis build. > I have tried and failed to lobby for this earlier, but one more try > can't hurt, I suppose :) Can we restrict -Werror to gcc builds, for the time being? If not, I agree with you, and it needs to go... Valid (and unambiguous) C statements shouldn't cause warnings, and we shouldn't add patches just because an old version of a certain compiler is silly. gert
On 28/11/2019 20:43, Gert Doering wrote: > hi, > > On Thu, Nov 28, 2019 at 11:56:34AM -0500, Selva Nair wrote: >> I think the correct fix here is to remove -Werror from travis build. >> I have tried and failed to lobby for this earlier, but one more try >> can't hurt, I suppose :) > > Can we restrict -Werror to gcc builds, for the time being? > > If not, I agree with you, and it needs to go... > > Valid (and unambiguous) C statements shouldn't cause warnings, and we > shouldn't add patches just because an old version of a certain compiler > is silly. With GCC-4.3.8, I see this warning: crypto.c: In function ‘write_pem_key_file’: crypto.c:1860:12: warning: missing braces around initializer [-Wmissing-braces] struct key server_key = { 0 }; Perhaps we should just add -Wno-missing-braces? A quick patch is attached, this silences this warning with GCC-4.3.8 at least. That said, I'm not sure this is the best approach; it may hide other missing braces warnings we should see.
I upgraded clang to 9.0 and warning disappeared. https://travis-ci.org/lstipakov/openvpn/builds/618527918 Patch is on the list. to 28. marrask. 2019 klo 21.44 Gert Doering (gert@greenie.muc.de) kirjoitti: > hi, > > On Thu, Nov 28, 2019 at 11:56:34AM -0500, Selva Nair wrote: > > I think the correct fix here is to remove -Werror from travis build. > > I have tried and failed to lobby for this earlier, but one more try > > can't hurt, I suppose :) > > Can we restrict -Werror to gcc builds, for the time being? > > If not, I agree with you, and it needs to go... > > Valid (and unambiguous) C statements shouldn't cause warnings, and we > shouldn't add patches just because an old version of a certain compiler > is silly. > > gert > > -- > "If was one thing all people took for granted, was conviction that if you > feed honest figures into a computer, honest figures come out. Never > doubted > it myself till I met a computer with a sense of humor." > Robert A. Heinlein, The Moon is a Harsh > Mistress > > Gert Doering - Munich, Germany > gert@greenie.muc.de > _______________________________________________ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel >
Hi,
On Fri, Nov 29, 2019 at 11:47:02AM +0100, David Sommerseth wrote:
> With GCC-4.3.8, I see this warning:
This is about as old as you :-) - do we care about suppressing warnings
in old gcc versions that might suppress a *relevant* warning when
compiling with a current gcc version?
gert
On 29/11/2019 11:52, Gert Doering wrote: > Hi, > > On Fri, Nov 29, 2019 at 11:47:02AM +0100, David Sommerseth wrote: >> With GCC-4.3.8, I see this warning: > > This is about as old as you :-) - do we care about suppressing warnings > in old gcc versions that might suppress a *relevant* warning when > compiling with a current gcc version? This is the default compiler on stock RHEL-7 ... which goes EOL August 2024.
Hi, On Fri, Nov 29, 2019 at 12:25:13PM +0100, David Sommerseth wrote: > On 29/11/2019 11:52, Gert Doering wrote: > > On Fri, Nov 29, 2019 at 11:47:02AM +0100, David Sommerseth wrote: > >> With GCC-4.3.8, I see this warning: > > > > This is about as old as you :-) - do we care about suppressing warnings > > in old gcc versions that might suppress a *relevant* warning when > > compiling with a current gcc version? > > This is the default compiler on stock RHEL-7 ... which goes EOL August 2024. We're not going to break it. I'm just not going to care very much about the warnings it might throw (and I might object to any patches that are "just for the benefit of suppressing warnings from gcc-4"). gert
On 29/11/2019 12:37, Gert Doering wrote: > Hi, > > On Fri, Nov 29, 2019 at 12:25:13PM +0100, David Sommerseth wrote: >> On 29/11/2019 11:52, Gert Doering wrote: >>> On Fri, Nov 29, 2019 at 11:47:02AM +0100, David Sommerseth wrote: >>>> With GCC-4.3.8, I see this warning: >>> >>> This is about as old as you :-) - do we care about suppressing warnings >>> in old gcc versions that might suppress a *relevant* warning when >>> compiling with a current gcc version? >> >> This is the default compiler on stock RHEL-7 ... which goes EOL August 2024. > > We're not going to break it. > > I'm just not going to care very much about the warnings it might throw > (and I might object to any patches that are "just for the benefit of > suppressing warnings from gcc-4"). Fair enough. But that will actually restrain us from adding -Werror by default for some time forward, unless we want to make package maintenance a bit more tricky - needing to revert a -Werror chage or add -Wno-missing-braces. If we have status quo for the moment, I can live with that until RHEL-7 is EOL.
Hi, On Fri, Nov 29, 2019 at 01:22:26PM +0100, David Sommerseth wrote: > > I'm just not going to care very much about the warnings it might throw > > (and I might object to any patches that are "just for the benefit of > > suppressing warnings from gcc-4"). > > Fair enough. But that will actually restrain us from adding -Werror by > default for some time forward, unless we want to make package maintenance a > bit more tricky - needing to revert a -Werror chage or add > -Wno-missing-braces. If we have status quo for the moment, I can live with > that until RHEL-7 is EOL. I don't think we can add -Werror as "on by default" for any platform in the foreseeable future - we'll always hit "old" or "too new" compilers that cause build breakage and lots of extra effort to work around it. Now, well-defined environments ("travis, clang-9, Linux") I'm all for it :) gert
diff --git a/src/openvpn/crypto.c b/src/openvpn/crypto.c index 65e789ed..731f5bad 100644 --- a/src/openvpn/crypto.c +++ b/src/openvpn/crypto.c @@ -1857,7 +1857,7 @@ void write_pem_key_file(const char *filename, const char *pem_name) { struct gc_arena gc = gc_new(); - struct key server_key = { 0 }; + struct key server_key = {{ 0 }}; struct buffer server_key_buf = clear_buf(); struct buffer server_key_pem = clear_buf(); diff --git a/src/openvpn/crypto_mbedtls.c b/src/openvpn/crypto_mbedtls.c index 3e77fa9e..57ad85ad 100644 --- a/src/openvpn/crypto_mbedtls.c +++ b/src/openvpn/crypto_mbedtls.c @@ -304,7 +304,7 @@ mbedtls_ctr_drbg_context * rand_ctx_get(void) { static mbedtls_entropy_context ec = {0}; - static mbedtls_ctr_drbg_context cd_ctx = {0}; + static mbedtls_ctr_drbg_context cd_ctx = {{0}}; static bool rand_initialised = false; if (!rand_initialised)