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 12721 invoked from network); 27 Nov 2023 22:23:48 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 27 Nov 2023 22:23:48 -0000 Received: from mail-ot1-f49.google.com ([209.85.210.49]) by 9front; Mon Nov 27 17:21:14 -0500 2023 Received: by mail-ot1-f49.google.com with SMTP id 46e09a7af769-6ce353df504so3027101a34.3 for <9front@9front.org>; Mon, 27 Nov 2023 14:21:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701123671; x=1701728471; darn=9front.org; h=content-transfer-encoding:in-reply-to:content-language:references :to:subject:user-agent:mime-version:date:message-id:from:from:to:cc :subject:date:message-id:reply-to; bh=XXohuT//lVq4UOmiKlhIKYyFwPWpCngGEuqLoa3TqyQ=; b=FKIEpiBdEpugdDBTW97078DGdwokd4bM7MB5iZSgAkGPsk6kaRl/vYbiSplsHbjObt bHjpu5AiBPt34EXr9ofOhRFf8ypyInWI4Mx0HeP9BXrvvzi4JpNnYbBRE6iAuV1hGRzL g2ii9/fS3bKeQS5O6hY95GJzFhK8/1tTDqv0X94ssZZUCzvbhDZxbKy5CNIK+Bj03UEP 4Xytl4+8kB+UxGuXz9qMc37pk77MOUQZ55ahxW9byxUxrMCeYFgoqg0bGXP6N7cOX9zU p+bM4iGd6/aW/881ZZtzOR6rHn2MWyNg3yoHhI8vyM3ER6UlUTlmn03dsxKvXcaPQYOP re7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701123671; x=1701728471; h=content-transfer-encoding:in-reply-to:content-language:references :to:subject:user-agent:mime-version:date:message-id:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=XXohuT//lVq4UOmiKlhIKYyFwPWpCngGEuqLoa3TqyQ=; b=ehMdEtNlX8PRzhixATe+TJOtUb+fQGDjEr9dVIiaP3sMb7kKPE8kyXovMsrecvfw5+ Hv3Uc/FEmSOrsGmgcFD2VodP6YLsMytw+if7fRPapLwLxeKL+eBCJLfPf/IVrSX66PqF X4iz0r8Z3HgjNsnwlmHGtEbyrrDXIXTi6oHTq3S3dRIVasssx+ZfdpIKYlqRBS4NdVQW ydMPU7bAH7kCwLFjt2E/fMoo492cRQNtNQC2iUvScWMDuj7nrYPHw6yzytTAnwWyv6Kt GOc0oNbnhJ9a5oGhfaru3R1mwUbbeiezff5D796ejLD1ILwNDqb3mawBx/KdEqiGa8lh NsMA== X-Gm-Message-State: AOJu0YxEf+7FSUvYIt/GhjZmoxD1P0Yzu6lUc7SRr9S1ztTgUD6HRqdR J+UWvLCDco/W530ZCO3cNN5mIKRUC3N4pw== X-Google-Smtp-Source: AGHT+IGB615DYYLe81jJCzHsyVLKyz7b20a0FVpeLGO4r9PQSutiGn56rJeUNHSrqRhrkappwpZzQA== X-Received: by 2002:a05:6830:1556:b0:6d8:1711:1ab with SMTP id l22-20020a056830155600b006d8171101abmr8328939otp.29.1701123671346; Mon, 27 Nov 2023 14:21:11 -0800 (PST) Return-Path: Received: from ?IPV6:2600:1700:e4c0:9ea0::5f6? ([2600:1700:e4c0:9ea0::5f6]) by smtp.gmail.com with ESMTPSA id f22-20020a9d6c16000000b006d7ed2ad9e8sm1493546otq.12.2023.11.27.14.21.10 for <9front@9front.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Nov 2023 14:21:10 -0800 (PST) From: Blue-Maned_Hawk X-Google-Original-From: Blue-Maned_Hawk Message-ID: <2bb2059a-2376-4d3a-8a30-9628603d3fde@invalid.invalid> Date: Mon, 27 Nov 2023 17:21:09 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: 9front@9front.org References: Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: progressive generic ORM over XML hardware browser optimizer Subject: Re: [9front] [PATCH] Fix assert macro to not break on commas Reply-To: 9front@9front.org Precedence: bulk On 11/27/23 10:38, ori@eigenstate.org 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 macro >>>> 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 weird? >>>> Because i can thing of a way to define such a thing: >>>> >>>> #define assert_msg(cond, msg) ((cond) ? (void)0 : (print(msg), exits(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(msg), >> 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); > Well, the first problem there is that you don't have a message in that invocation, so it's going to break anyway. However, if you were to invoke it as e.g. assert_msg("Magic octopus", (Thing){0, "foo"}.a, (Thing){1, "bar"}.b); it would not break.