From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=YL822ifR; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id 8B5EC5A027C for ; Mon, 19 May 2025 09:27:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1747639627; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6GZYyc8XT7A0iFCOlzYVtEIBGbI5RPHj16dO5xFX87s=; b=YL822ifRlsjBDIBSPBbHXvI82rzsiBwuOl2sgpxh+rGFRcuFOdHom3zVLzoBP6Fulugf25 KxEUenG2zJPSlQL/l7AESDUJ8ckilxuxCp9W8JJ1uGzlivFeJAqRMY/ZQ9r6EDvNWh4rSb WdpON3iZLi924WWR8Ygv8kiCFQSOv+4= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-595-oZk2_uauNVmR7AaSWhOQ_Q-1; Mon, 19 May 2025 03:27:05 -0400 X-MC-Unique: oZk2_uauNVmR7AaSWhOQ_Q-1 X-Mimecast-MFC-AGG-ID: oZk2_uauNVmR7AaSWhOQ_Q_1747639624 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-43cf172ff63so21303075e9.3 for ; Mon, 19 May 2025 00:27:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747639624; x=1748244424; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=6GZYyc8XT7A0iFCOlzYVtEIBGbI5RPHj16dO5xFX87s=; b=XX6DcJofxJANs0aRBBRl34fknUHoLGFoRbWaBpH6H60kNEtXYkXdJoZXUrCyKxFyRr DCB0vibxYjr+GUALQ+Vrl7MS+Aael3HLtrpbV294lhRIbzPCyaYr0VxQVTkQODQsXqY/ EUnJyHtb6a7gRX9IFfVRPIfGBBza/IW3Xx+mGBoMJECdiaDsuxCCIXgzSdCXUms+7XdO WM4wluyqpJ1N8Gn2p7ZZJZ7/zWuRYDeuEYhjQcc17W9Qzdvtg8NUF5wFmsdPryHMixUo hDRkbLZGa5K+T2WaQeT6n2yeygj7EL0/xAaMP9DeyK2NxnJr++BgZ2Hradok2+K4Ptx7 S/vw== X-Gm-Message-State: AOJu0YygIGpng74pNmctnNIiTP0rbkH8VH8zCu5jalUqZjTPYoPuBXqI 1U8tTR/IbXiz83staU+ubj2DmnS2v9JewmwSlLcqJjlrOo0zkuhUqtncaWe6tdiwU3pjzwX3rSx PmCb7HSRRyBzWEAo1tbT/dG6iwOofKdmFRSqVVWZG9V6gHzj6uvTSZS6xy2pSbA== X-Gm-Gg: ASbGncuL2WA6jd+U+cghntXg2WMmz+kiOppfFfeP0FC7UmOlHiFR92+mrhbABqlFQHb f9rSGE9GzjZ6wS8AEhhJQt83dxnp/s4QplyPjYBbqqSyBpfjJlvez9DLp50Yx+WNIw6KBuWw8mf M0L+XzuD51siOeEdH3x31ItlThwTFrK9FcH9dijySHiSjkip8W7afVw6hdMEhhmBdZyGAiGZfEL /ucVZOiTcj8phxnJEy+FH/ZGkSsYnVnY5Wl1WACGH/NSFLqhKOt89QZXBtGIf7dFsOkOSjsnkeT Q9cfgXACnVzFTsYrzYMwcuDbxiLDeZdpCCgxqeFM X-Received: by 2002:a05:600c:3588:b0:442:d5dd:5b4b with SMTP id 5b1f17b1804b1-442fd67861amr117011835e9.31.1747639623660; Mon, 19 May 2025 00:27:03 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHjVlxXbCPburvfHZmfcdoXrt7uKCH08DC7d3qD+ZxzIwBcgMZ466eL2g9xu+1SJoPVyMfcFw== X-Received: by 2002:a05:600c:3588:b0:442:d5dd:5b4b with SMTP id 5b1f17b1804b1-442fd67861amr117011625e9.31.1747639623255; Mon, 19 May 2025 00:27:03 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a36749f622sm7886469f8f.93.2025.05.19.00.27.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 May 2025 00:27:02 -0700 (PDT) Date: Mon, 19 May 2025 09:27:01 +0200 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH] tap: Avoid bogus missingReturn cppcheck warning in tap_l2_max_len() Message-ID: <20250519092701.68b2c6f0@elisabeth> In-Reply-To: References: <20250515160501.2636220-1-sbrivio@redhat.com> <20250516182623.69e49c29@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: qzlVZrNdH_VJQZlGNEc7WemzmJjESf2ko-CEQT-G_xo_1747639624 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: 5FDO2NZQ3BBMAFGLUF2HLVMPWAU3DVBG X-Message-ID-Hash: 5FDO2NZQ3BBMAFGLUF2HLVMPWAU3DVBG X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Sat, 17 May 2025 20:29:20 +1000 David Gibson wrote: > On Fri, May 16, 2025 at 06:26:23PM +0200, Stefano Brivio wrote: > > On Fri, 16 May 2025 17:25:21 +1000 > > David Gibson wrote: > > > > > On Thu, May 15, 2025 at 06:05:01PM +0200, Stefano Brivio wrote: > > > > Cppcheck 2.14.2 on Alpine Linux (musl) says that: > > > > > > > > tap.c:111:19: error: Found an exit path from function with non-void return type that has missing return statement [missingReturn] > > > > switch (c->mode) { > > > > ^ > > > > > > > > This exit path is not reachable because we ASSERT(0) after the switch, > > > > but for some reason cppcheck doesn't see this with musl headers. Hide > > > > the warning with a redundant return statement. > > > > > > > > Signed-off-by: Stefano Brivio > > > > > > Hm. Alternatively you could change this to call abort_with_msg() > > > directly. That's marked as ((noreturn)) so with any luck cppcheck > > > will then be able to figure out what's going on. Although, I'm > > > slightly surprised it can't do so already: I thought I put the > > > ((noreturn)) in there to avoid warnings exactly like this. > > > > So, I checked, and abort_with_msg(""); works. ASSERT() ultimately > > expands to abort_with_msg(), but for some reason cppcheck together with > > Clang can't "follow" that, I suppose it's something related to the > > pre-processor. > > > > But in any case, abort_with_msg("") doesn't look as descriptive and > > as obviously redundant as a return statement with a comment, so I don't > > quite see the benefit changing it (also considering that I need to test > > other versions, which takes time). > > Well, kind of the whole point of abort_with_msg() is that you can give > it a meaningful message, which might change the picture. Right, but I was struggling with making it meaningful: "dodged cppcheck warning, you'll never see this"? I much prefer a return with a comment. > It would > also be trivial to write an unreachable() wrapper around that. Ah, that would be nice, yes. I would consider writing one after 2-3 more cases like this. -- Stefano