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=RLBWvkyK; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id A58045A0262 for ; Tue, 17 Mar 2026 10:36:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1773740190; 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=MLBS4GCnAf0BjlNNpxuMk7BdD/jCJ9ycAq5uITl1G5k=; b=RLBWvkyKKcUKdOkyD5if6BiPXeWcKNrP6wbwmJTiurKpM4g4039tKwbPUka6i681cpEgzW slK2vxjgX8bEvYoSz0WCwpEcdsrHCIR4r1RXH33uQFfr6I42VVdtrwxPCDuK3vS3DD+5iE BPjYv6URctundp1A8I38Gu44renxGZw= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-660-gfp7ZKlqOoiLZmY8ZwlfuA-1; Tue, 17 Mar 2026 05:36:29 -0400 X-MC-Unique: gfp7ZKlqOoiLZmY8ZwlfuA-1 X-Mimecast-MFC-AGG-ID: gfp7ZKlqOoiLZmY8ZwlfuA_1773740188 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-439cbfcfc21so5360042f8f.2 for ; Tue, 17 Mar 2026 02:36:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773740187; x=1774344987; h=date:content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=LAnuZ3uulALYJJEWXchURpGVhgPUZrKkljJ8F32hySI=; b=C3hTFyvUjO/Z/154euAHDqnarBIwfOdCU48qLsaugqwt5INtk0w56wGvOKhLhpwwXa QnQkaSuQjuRYStdAPY28C//AWpV2xtwVVpr7ZSFEGwzW+QGHJkIaM2XvrrnDrqb6h8Wj OGR1sg8AILiH2cXpEmraU+TA9LoOrkOetXAV7bV/U4FIJ1QxZVcENOgY9jRojqvJWmuI 3CxuzL7nF9m9smzJ4dmn+qiV5KqMWoxGEuXUlM45mI95L7yJ0uozqoqwdbUSxbAtMezp z+cuwKxmm6N3Y5WAYXpeBRlo3lZB997ywGy8Nf7g4ScOzyoNsCVEhRF42j+7YjuwmeDN VHHw== X-Gm-Message-State: AOJu0YzYyGjt1+u+bN0Sz2hQQo5IYl3JoYnNhfHGpSdK3UvE+v/aX/W1 pikUgzymqoCRxNzoKRjofg9l4o+O4Jiq4bqGlB8++TWgrvvUTJel1qWbQbc44POzFEWWODagnWO n4f6hW1BlxKPBgKViZpY/ULsfKvKD1+2kAzFxTEMXK67YUCNzLnSWAU63vTeiIg== X-Gm-Gg: ATEYQzxaoN3XI1S2FLE7+pD0+8eZEq/qGVxdlho/I4/xqZ9E0OqHuy/DMcRpziru2St CNTEQlJC6kdxvmLpQlr53wUWJwOTbjq/IbU6lUg0IPjxqzcJjueq6KdI46fBwOLPDR5VxcCtl0h xyo5mgx7iLUk+9hSSEHK20ePMTNZnh3KvDjbJFdqLOnagki00U5+eTtoUvHD5KOm8zSvuuBjn+k iS9o3khGG0DBSGlAbkGNk1g1jiud251IBg8kUeabAbDj2DTOzCDjRUdaqs1J95cIQWk5Hp6hNAB Cbkov3hLIclC/bYRmk2eKaaz3kruVyBuxiTDhUYtxatVyth3aJDt32JKgYqE2XKpznGhbu/o5oq 7OQiRV/HzhX78DAQduyTtcOtcdChdc7QjFVi+TdXYKxw9GubhzA== X-Received: by 2002:a05:6000:2084:b0:43b:4920:56bb with SMTP id ffacd0b85a97d-43b492057afmr6080316f8f.52.1773740187295; Tue, 17 Mar 2026 02:36:27 -0700 (PDT) X-Received: by 2002:a05:6000:2084:b0:43b:4920:56bb with SMTP id ffacd0b85a97d-43b492057afmr6080254f8f.52.1773740186657; Tue, 17 Mar 2026 02:36:26 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439fe20bd9csm49337717f8f.21.2026.03.17.02.36.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Mar 2026 02:36:26 -0700 (PDT) From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 4/5] treewide: Spell ASSERT() as assert() Message-ID: <20260317103624.7b547b48@elisabeth> In-Reply-To: References: <20260316054629.239002-1-david@gibson.dropbear.id.au> <20260316054629.239002-5-david@gibson.dropbear.id.au> <20260317010233.0723ea6d@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 Date: Tue, 17 Mar 2026 10:36:25 +0100 (CET) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 7fY0JxTv7W5TdRDhFsn_sSOEe0sf7JiZBZxsGuNSPKQ_1773740188 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: RL6JXHVOZUWA35NQHROJQK3Z6ACUTETJ X-Message-ID-Hash: RL6JXHVOZUWA35NQHROJQK3Z6ACUTETJ 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 Tue, 17 Mar 2026 11:39:42 +1100 David Gibson wrote: > On Tue, Mar 17, 2026 at 01:02:34AM +0100, Stefano Brivio wrote: > > On Mon, 16 Mar 2026 16:46:28 +1100 > > David Gibson wrote: > > =20 > > > +++ b/util.h > > > @@ -73,10 +73,14 @@ void abort_with_msg(const char *fmt, ...) > > > * Therefore, avoid using the usual do while wrapper we use to force= the macro > > > * to act like a single statement requiring a ';'. > > > */ > > > -#define ASSERT_WITH_MSG(expr, ...)=09=09=09=09=09\ > > > +#define assert_with_msg(expr, ...)=09=09=09=09=09\ > > > =09((expr) ? (void)0 : abort_with_msg(__VA_ARGS__)) > > > -#define ASSERT(expr)=09=09=09=09=09=09=09\ > > > -=09ASSERT_WITH_MSG((expr), "ASSERTION FAILED in %s (%s:%d): %s",=09\ > > > +/* The standard library assert() hits our seccomp filter and dies be= fore it can > > > + * actually print a message. So, replace it with our own version. > > > + */ > > > +#undef assert > > > +#define assert(expr)=09=09=09=09=09=09=09\ > > > +=09assert_with_msg((expr), "ASSERTION FAILED in %s (%s:%d): %s",=09\ > > > =09=09=09__func__, __FILE__, __LINE__, STRINGIFY(expr)) =20 > >=20 > > While looking this up to make sure it's specified as a macro (it is, > > and this builds against musl as well), I realised that POSIX.1-2024 > > says: > >=20 > > https://pubs.opengroup.org/onlinepubs/9799919799/functions/assert.htm= l > >=20 > > Forcing a definition of the name NDEBUG, either from the compiler > > command line or with the preprocessor control statement #define NDEBU= G > > ahead of the #include statement, shall stop assertions fro= m > > being compiled into the program. > >=20 > > ...so, I wonder, now that it's called assert(), should we define it as > > "do { } while(0)" #ifdef NDEBUG, for correctness (and maybe somebody > > has obscure usages for NDEBUG which we shouldn't sabotage)? =20 >=20 > I like the idea in principle. Actually implementing it turns out to > be kind of a pain in the arse, because if we actually try to compile > with -DNDEBUG then we get a much of warnings due to reaching the end > of functions (assert(0) stopped us otherwise) or unused variables > (they're only used in the assert expression or message). >=20 > A project for some other time, I think. Well but it's just (probably harmless) warnings right? I tried with this on top of your patch: --- diff --git a/util.h b/util.h index dcb79af..77b59bc 100644 --- a/util.h +++ b/util.h @@ -75,13 +75,18 @@ void abort_with_msg(const char *fmt, ...) */ #define assert_with_msg(expr, ...)=09=09=09=09=09\ =09((expr) ? (void)0 : abort_with_msg(__VA_ARGS__)) + /* The standard library assert() hits our seccomp filter and dies before i= t can * actually print a message. So, replace it with our own version. */ #undef assert +#ifdef NDEBUG +#define assert(expr)=09do { } while(0) +#else #define assert(expr)=09=09=09=09=09=09=09\ =09assert_with_msg((expr), "ASSERTION FAILED in %s (%s:%d): %s",=09\ =09=09=09__func__, __FILE__, __LINE__, STRINGIFY(expr)) +#endif =20 #ifdef P_tmpdir #define TMPDIR=09=09P_tmpdir --- and 'CFLAGS=3D"-DNDEBUG" make' gives me some stuff such as, for example: util.c: In function =E2=80=98sock_l4_=E2=80=99: util.c:90:14: warning: =E2=80=98proto=E2=80=99 may be used uninitialized [-= Wmaybe-uninitialized] 90 | fd =3D socket(af, socktype, proto); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ because an invalid value for it isn't caught by assert(0) anymore, but from a quick review I'd say it's all intended and implied because of the missing assert() calls. Sure, the output with NDEBUG is not pretty, but we won't be able to "fix" most of that anyway. If somebody passes it as extra CFLAGS, I would expect they know what they're doing. Nobody will build distribution packages or anything "official" with it, I think. Either way, should I go ahead and merge this (in the original version or amended for NDEBUG, I'm fine with both)? --=20 Stefano