From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 30495 invoked from network); 27 Nov 2023 16:02:11 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 27 Nov 2023 16:02:11 -0000 Received: from mail-lj1-f178.google.com ([209.85.208.178]) by 9front; Mon Nov 27 10:59:47 -0500 2023 Received: by mail-lj1-f178.google.com with SMTP id 38308e7fff4ca-2c50fbc218bso54248961fa.3 for <9front@9front.org>; Mon, 27 Nov 2023 07:59:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701100783; x=1701705583; darn=9front.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=PdkZDrBwBO6zor9qlzA0LEC4i0mea1p0I5Ppm1HoVHk=; b=SkIyM73jrBlZeVILd5baHE7jKMTQ7Ii4Jx0thF7d9K8XT/j/UyA/JFA1cP6wxlG2QY N1IpRLdmAU9BnQWq3to0M9PX5v9LBUqffO3G1ZdbFk2aWAHqX9xPyS7yLHtbIxL+5/wT 8+61uYVc9VHRgg+jsOEC70op36K+dFDA/qfKu2v7EDB0psA6fOp0tQNEwLgVhyS9HWHh 8fkKCZYbYvhLFiW2Uzij7uchdcRO+fUuwGQh/FubM8mSXvkPtlSiiHJBHyVpAR26fuuA Qyjr7ICgHuSA/CISQVLkYdP1Dxo0WkDddSBd8FNhaUQKTrLJ4EO7QllH/U48ZylAWa6r 8W/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701100783; x=1701705583; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PdkZDrBwBO6zor9qlzA0LEC4i0mea1p0I5Ppm1HoVHk=; b=HylWyUDSx01P4A6jm3K8A/8zSvLxbdjrI+dovq2W2AzOLasw9UboWw60DZg8/XXPHO 5rQk6UTJG4EnJtLa/AR04sqRqVbrozZlTGc9OkroJNlhfu2ACpKYq3pv1lrxBpnPaQQm GLiD8uA9yuCEA+pM7616KZgi8q8iYzv+lKlKmtqY/PBXXTnPgZML2EUlZeWuQ7/ziEp3 lTdjYrWSKspLRttqNVdbmy4Ay1N4MixnbgTp3c00Xe/j9+e1mAzfAsf8sTyO2FBbEWjp +DWwvNDc+zA2EAmo8RgaQfxu2NNjiXSfQ0i64cMpehJQIDsi8fAiIG/D73oU5wv4JoM2 JvwA== X-Gm-Message-State: AOJu0Yx2T+TQR9g/iJAOYv6DRBLZd4DRE6vLtEnsExxk9l75gPTHcbU0 RG65/7JMpuz/rZyHRti1MtHbhhdOPqm1t+ko/MdqTSOd X-Google-Smtp-Source: AGHT+IEnBipc6bDMDPYjrzG52/Dqp0AdKvokPFeP0bJqW0Sfu4mfwFlYkBmu/0fkdq2e2Xv89g5CEYpKYXjX5mLN6Ak= X-Received: by 2002:a2e:91cc:0:b0:2c8:7173:6123 with SMTP id u12-20020a2e91cc000000b002c871736123mr8862430ljg.32.1701100782999; Mon, 27 Nov 2023 07:59:42 -0800 (PST) MIME-Version: 1.0 References: <53a49e38-03e2-4425-bbb7-25e88523153e@invalid.invalid> In-Reply-To: From: Dan Cross Date: Mon, 27 Nov 2023 10:59:06 -0500 Message-ID: To: 9front@9front.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: cloud base configuration STM framework Subject: Re: [9front] [PATCH] Fix assert macro to not break on commas Reply-To: 9front@9front.org Precedence: bulk On Mon, Nov 27, 2023 at 10:40=E2=80=AFAM wrote: > Quoth Blue-Maned_Hawk : > > On 11/26/23 19:00, ori@eigenstate.org wrote: > > > Quoth Blue-Maned_Hawk : > > >> On 11/26/23 17:52, ori@eigenstate.org wrote: > > >>> Quoth Blue-Maned_Hawk : > > >>>> What reason have y'all for avoiding macros? > > >>> > > >>> Well, the fact that you need hacks like the one that started this > > >>> thread, for one; > > >> > > >> I don't see how it's a hack, but maybe i've just become numb to macr= o > > >> shenaniganry. > > >> > > >>> what if you had macro that took *two* arguments? > > >>> > > >>> #define assert_msg(cond, msg) \ > > >>> ...what here? > > >>> > > >>> I don't see how you can avoid just saying "it's a macro, it's going > > >>> to be weird, don't even try". > > >>> > > >> > > >> Don't even try writing the macro or don't even try making it not wei= rd? > > >> Because i can thing of a way to define such a thing: > > >> > > >> #define assert_msg(cond, msg) ((cond) ? (void)0 : (print(msg), ex= its(msg))) > > >> > > >> and i don't think that that's a particularly weird way to do so. > > > > > > > > > Wouldn't that fall apart on the same case that you showed above? > > > > > > assert_msg((Thing){0, 1}.a, "foo"); > > > > > > > Aye, correct you are. In that case, it could be rearranged to > > > > #define assert_msg(msg, ...) ((__VA_ARGS__) ? (void)0 : (print(ms= g), > > exits(msg))) > > > > and it would be able to tolerate unparenthesized commas in the checked > > expression. > > assert_msg((Thing){0, "foo"}.a, (Thing){1, "bar"}.b); It seems like one could keep going with more complex macros and every expanded use on those macros to demonstrate that the way program text is parsed in the preprocessor and the language proper is different. But this is getting a bit far away from the original change suggestion, which was substituting three symbols in a single macro for a different three symbols. Whether that's worth it just to avoid a set of parentheses when using the comma operator or a struct literal in an `assert` is debatable, but the difference in complexity is pretty much negligible. Regardless, I'd suggest that almost no one implements `assert()` the suggested way, and it would be just another gratuitous difference between the C used here and the rest of the world; that alone is enough to reject the patch (to me anyway; you all do you). - Dan C.