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.0 required=5.0 tests=T_SCC_BODY_TEXT_LINE
	autolearn=ham autolearn_force=no version=3.4.4
Received: (qmail 20024 invoked from network); 25 Nov 2023 04:50:48 -0000
Received: from 9front.inri.net (168.235.81.73)
  by inbox.vuxu.org with ESMTPUTF8; 25 Nov 2023 04:50:48 -0000
Received: from mimir.eigenstate.org ([206.124.132.107]) by 9front; Fri Nov 24 23:49:35 -0500 2023
Received: from abbatoir (pool-108-6-24-2.nycmny.fios.verizon.net [108.6.24.2])
	by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id b6ef02cb (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO)
	for <9front@9front.org>;
	Fri, 24 Nov 2023 20:49:34 -0800 (PST)
Message-ID: <F6B1EC1ABE420DC89EC13E2E2707FD16@eigenstate.org>
To: 9front@9front.org
Date: Fri, 24 Nov 2023 23:49:33 -0500
From: ori@eigenstate.org
In-Reply-To: <8708ecaa-0b89-430d-ad06-2fd272680660@invalid.invalid>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: managed WEB2.0 over SSL blockchain service map/reduce CSS control 
Subject: Re: [9front] [PATCH] Fix assert macro to not break on commas
Reply-To: 9front@9front.org
Precedence: bulk

Quoth Blue-Maned_Hawk <bluemanedhawk@gmail.com>:
> On 11/22/23 23:20, Jacob Moody wrote:
> > On 11/22/23 17:11, Blue-Maned_Hawk wrote:
> >> This is a pair of patches that changes the assert macro to be variadic,
> >> allowing expressions with commas in them to be used without needing a
> >> spare pair of parentheses, and updates the manpage accordingly.
> >> 
> > 
> > For what reason does this need changed?
> 
> To avoid (admittedly, edge) cases where a comma in the expression being 
> asserted would be incorrectly interpretted as an attempt to invoke a 
> single-argument macro with two or more arguments.
> 
> > Is there some code you're working with expecting this?
> 
> No.
> 
> > I am inclined to prefer to keep this as is.
> 
> Why?
> 


...for that matter, I'd be more inclined to remove
the stringification from the assert, and just make
it into a regular function:

	void assert(int);

and make the relevant adjustments; you have the snap
when the abort triggers, so there's not really much
need to print the condition.