[9front] [PATCH] Fix assert macro to not break on commas

[9front] [PATCH] Fix assert macro to not break on commas

[Blue-Maned_Hawk]

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.
\x1f
diff 04d6a2acecfe4fe44947da8b676f63bcd0f3c0fe uncommitted
--- a/sys/include/libc.h
+++ b/sys/include/libc.h
@@ -3,7 +3,7 @@

  #define	nelem(x)	(sizeof(x)/sizeof((x)[0]))
  #define	offsetof(s, m)	(ulong)(&(((s*)0)->m))
-#define	assert(x)	if(x){}else _assert("x")
+#define	assert(...)	if(__VA_ARGS__){}else _assert("__VA_ARGS__")

  /*
   * mem routines
\x1f
diff 04d6a2acecfe4fe44947da8b676f63bcd0f3c0fe uncommitted
--- a/sys/man/2/assert
+++ b/sys/man/2/assert
@@ -7,7 +7,7 @@
  .B #include <libc.h>
  .PP
  .B
-#define assert(cond) if(cond);else _assert("cond")
+#define assert(...) if(__VA_ARGS__){}else _assert("__VA_ARGS__")
  .PP
  .B
  void _assert(char* cond)

Re: [9front] [PATCH] Fix assert macro to not break on commas

[Jacob Moody]

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.
> \x1f

For what reason does this need changed? Is there some code you're working
with expecting this? I am inclined to prefer to keep this as is.

Re: [9front] [PATCH] Fix assert macro to not break on commas

[Blue-Maned_Hawk]

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.
>> \x1f
> 
> 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?

Re: [9front] [PATCH] Fix assert macro to not break on commas

[Jacob Moody]

On 11/24/23 18:27, Blue-Maned_Hawk wrote:
> 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.
>>> \x1f
>>
>> 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.

This a problem that can be avoided by just using the interface correctly.

> 
>> Is there some code you're working with expecting this?
> 
> No.
> 
>> I am inclined to prefer to keep this as is.
> 
> Why?
> 

I am generally against increasing the complexity of our macros unless
there is a good enough usecase for it, which I have not been convinced of
here.

Re: [9front] [PATCH] Fix assert macro to not break on commas

[ori]

Quoth Blue-Maned_Hawk <bluemanedhawk@gmail.com>:
> 
> 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.

Assert should largely behave like a function; the only reason
it's a macro is for slightly better debug prints.

We don't try to make functions take comma expressions in the
argument lists either.

	sin(1,2); // also errors;

If you really need a comma expression, you can parenthesize it,
just like you would for a function call.

	assert((expr,list))

Re: [9front] [PATCH] Fix assert macro to not break on commas

[ori]

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.
> >> \x1f
> > 
> > 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.

Re: [9front] [PATCH] Fix assert macro to not break on commas

[Blue-Maned_Hawk]

On 11/24/23 23:34, ori@eigenstate.org wrote:
> Assert should largely behave like a function; the only reason
> it's a macro is for slightly better debug prints.
> 
> We don't try to make functions take comma expressions in the
> argument lists either.
> 
> 	sin(1,2); // also errors;
> 
> If you really need a comma expression, you can parenthesize it,
> just like you would for a function call.
> 
> 	assert((expr,list))
> 
> 

Ah, but see you now:  there are situations which break for a macro 
invocation, but not for a function call, such as the usage of a struct 
literal, because the preprocessor doesn't tokenize in the same way as 
the language itself.  Consider the following obviously-contrived situation:

	assert((struct Tm){.nsec = 0, .sec = 1}.sec);

Re: [9front] [PATCH] Fix assert macro to not break on commas

[Kurt H Maier]

On Sat, Nov 25, 2023 at 07:09:40AM -0500, Blue-Maned_Hawk wrote:
> On 11/24/23 23:34, ori@eigenstate.org wrote:
> > Assert should largely behave like a function; the only reason
> > it's a macro is for slightly better debug prints.
> > 
> > We don't try to make functions take comma expressions in the
> > argument lists either.
> > 
> > 	sin(1,2); // also errors;
> > 
> > If you really need a comma expression, you can parenthesize it,
> > just like you would for a function call.
> > 
> > 	assert((expr,list))
> > 
> > 
> 
> Ah, but see you now:  there are situations which break for a macro
> invocation, but not for a function call, such as the usage of a struct
> literal, because the preprocessor doesn't tokenize in the same way as the
> language itself.  Consider the following obviously-contrived situation:
> 
> 	assert((struct Tm){.nsec = 0, .sec = 1}.sec);

Making the language dumber because someone wants to do something stupid
is the wrong plan.

khm

Re: [9front] [PATCH] Fix assert macro to not break on commas

[Steve Simon]

i strongly agree with kurt.

this should go into the fortunes file imho.

> Making the language dumber because someone wants to do something stupid
> is the wrong plan.

Re: [9front] [PATCH] Fix assert macro to not break on commas

[Dan Cross]

On Sat, Nov 25, 2023, 3:12 PM Steve Simon <steve@quintile.net> wrote:
> i strongly agree with kurt.
>
> this should go into the fortunes file imho.
>
> > Making the language dumber because someone wants to do something stupid
> > is the wrong plan.

The statement is factually wrong. The language is already the way that
it is, and this change just makes a macro useful in more contexts;
that's not "changing the language" unless someone is adding the
variadic macro stuff to the compilers to do it.

        - Dan C.

Re: [9front] [PATCH] Fix assert macro to not break on commas

[Steve Simon]

iyou are quite right, assert() is part of the standard plan9 library, not the language.

however i honestly doubt this has caused a significant number of issues for plan9 programmers. i suggest it is just not worth changing.

i liked the general sentiment of kurt’s comments, but perhaps i am just a curmudgeon after all.

-Steve


> On 25 Nov 2023, at 8:40 pm, Dan Cross <crossd@gmail.com> wrote:
> 
> On Sat, Nov 25, 2023, 3:12 PM Steve Simon <steve@quintile.net> wrote:
>> i strongly agree with kurt.
>> 
>> this should go into the fortunes file imho.
>> 
>>> Making the language dumber because someone wants to do something stupid
>>> is the wrong plan.
> 
> The statement is factually wrong. The language is already the way that
> it is, and this change just makes a macro useful in more contexts;
> that's not "changing the language" unless someone is adding the
> variadic macro stuff to the compilers to do it.
> 
>        - Dan C.

Re: [9front] [PATCH] Fix assert macro to not break on commas

[Kurt H Maier]

On Sat, Nov 25, 2023 at 03:39:57PM -0500, Dan Cross wrote:
> On Sat, Nov 25, 2023, 3:12 PM Steve Simon <steve@quintile.net> wrote:
> > i strongly agree with kurt.
> >
> > this should go into the fortunes file imho.
> >
> > > Making the language dumber because someone wants to do something stupid
> > > is the wrong plan.
> 
> The statement is factually wrong. The language is already the way that
> it is, and this change just makes a macro useful in more contexts;
> that's not "changing the language" unless someone is adding the
> variadic macro stuff to the compilers to do it.
> 
>         - Dan C.

The statement is not 'factually wrong' according to this argument; it
would instead be irrelevant, which it very well might be.

I suppose this is an opportunity to be pedantic about where the line is
drawn between a language, the implementation of that language, and the
detritus that habitually grows around a language, but it's all
irrelevant, because I don't care.

Doing fancy shit with macros in places where you have the opportunity 
not to do fancy shit with macros is bad.  I know this goes against many
currently-popular dogmas, where we all love to build abstraction castles
into the sky, but there is a difference between making something
convenient and building yet another indirection layer some poor bastard
later has to unravel in order to understand what is happening.

This macro has been fine as it sits for a lot of use.  We have no
convincing demonstrations that this change will enable anything useful
that was not previously possible.  We have no arguments that it will
even make anything more convenient which isn't justifiably difficult at
the moment.  

Finally,I'm doubly suspicious of it because the submitter has a history 
of asshattery and obnoxious behavior in the irc channel.  If this patch
came from some drive-by rando I'd be less opposed to it; instead it
comes from someone with a recent history of willfully refusing to
communicate clearly, and is defended by someone who chose to support it
based on sophistry instead of any clear technical grounds.

I'm not gonna stop anyone from merging anything.  I don't have a dog in
this fight.  But the reasons given suck and further deponent sayeth
trash.

khm

Re: [9front] [PATCH] Fix assert macro to not break on commas

[Blue-Maned_Hawk]

On 11/25/23 21:22, Kurt H Maier wrote:
> Doing fancy shit with macros in places where you have the opportunity
> not to do fancy shit with macros is bad.

This change is not fancy.  It's the bare minimum for things like this.

> Finally,I'm doubly suspicious of it because the submitter has a history
> of asshattery and obnoxious behavior in the irc channel.  If this patch
> came from some drive-by rando I'd be less opposed to it; instead it
> comes from someone with a recent history of willfully refusing to
> communicate clearly, and is defended by someone who chose to support it
> based on sophistry instead of any clear technical grounds.

I'm just new around here.

Re: [9front] [PATCH] Fix assert macro to not break on commas

[ori]

Quoth Blue-Maned_Hawk <bluemanedhawk@gmail.com>:
> I'm just new around here.

In general, we try pretty hard to avoid doing stuff
in macros. There are places where it's unavoidable,
but excluding ape, there's more #ifdef in ghostscript
than in the rest of the system combined.

Re: [9front] [PATCH] Fix assert macro to not break on commas

[Amavect]

On Fri, Nov 24, 2023 at 6:29 PM Blue-Maned_Hawk <bluemanedhawk@gmail.com> wrote:
> > 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.

Concurring opinion to not change this.
Worst case is some valid programs don't compile.
Don't add needless abstraction for situations you don't have.

If you have programs that you want to compile,
just share the relevant code and either we'd start arguing about how to
make that code better, or just commit the macro patch.

Thanks,
Amavect

Re: [9front] [PATCH] Fix assert macro to not break on commas

[Kurt H Maier]

On Sun, Nov 26, 2023 at 12:31:52PM -0500, Blue-Maned_Hawk wrote:
> On 11/25/23 21:22, Kurt H Maier wrote:
> > Doing fancy shit with macros in places where you have the opportunity
> > not to do fancy shit with macros is bad.
> 
> This change is not fancy.  It's the bare minimum for things like this.

You still haven't even bothered to define "things like this" or make a
single argument for having them.  This is the sort of dipshit behavior
that got you kicked in IRC.

> I'm just new around here.

No, you're not.  Most of us got tired of your bullshit long ago.

khm

Re: [9front] [PATCH] Fix assert macro to not break on commas

[sirjofri]

Hello,

My 2 cents:

I think having that change is unnecessary, at least. It only makes the code look nicer a little bit, and not having it makes the programmer recognize the "bug" pretty early. I'm pretty sure the compiler will just complain and the programmer adds another set of parentheses, and that's it. Furthermore, it makes it clear that assert is a macro and not a function, leading to further care when developing applications (which is the job of a programmer anyways; having assert as is and dealing with extra parentheses and compiler errors is too small to cry for a change of how things are currently, in my humble opinion).

In addition to that, programmers should always be able to look at the functions they use. In this case it's obvious that assert is a macro. Furthermore, changing that macro makes 9front code that depends on that change incompatible with other 9 systems. Again, just a small thing that's easy to "fix", but it's incompatible.

Changing assert to a function is something I don't like to see. I know it's just a fancy way to add the point of error to the error output, but I'd like to have that. Bug reports suck, and most users don't know about crash dumps etc, they just paste the error and in that case I'd like to have that extra bit of information, in the rare cases I don't capture the error earlier with proper output for the user. Also, it's a common functionality that's well known across environments and also programming languages.

Last words that are important: It's not bad if a patch is rejected. Most of the time it's good, and also it's fine to do any changes in your local environment, or even distribute your own version of 9 with any changes you like. Gate keepers try their best to judge about the incoming patches to keep a minimum (or higher level) of quality. Of course it's also fine to argue, so keep up the good work on both sides. (Maybe I should've argued more about my factotum totp stuff, but I see the point: there's no application currently using it).

sirjofri

Re: [9front] [PATCH] Fix assert macro to not break on commas

[ori]

Quoth Blue-Maned_Hawk <bluemanedhawk@gmail.com>:
> 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.

Alternative proposal.

This prints the pid, which means you can now get a full
stack trace trivially with:

	lstk $pid

and plumb the paths into your editor, instead of getting
a pretty dumb context-free copy of the expression that
failed.

diff 276c090a9536c0165d10d908862a93e743d3b344 uncommitted
--- a/sys/include/libc.h
+++ b/sys/include/libc.h
@@ -3,7 +3,6 @@
 
 #define	nelem(x)	(sizeof(x)/sizeof((x)[0]))
 #define	offsetof(s, m)	(ulong)(&(((s*)0)->m))
-#define	assert(x)	if(x){}else _assert("x")
 
 /*
  * mem routines
@@ -384,7 +383,7 @@
 	PNGROUP		= 2,
 };
 
-extern	void	_assert(char*);
+extern	void	assert(int);
 extern	int	abs(int);
 extern	int	atexit(void(*)(void));
 extern	void	atexitdont(void(*)(void));
--- a/sys/man/2/assert
+++ b/sys/man/2/assert
@@ -6,17 +6,12 @@
 .br
 .B #include <libc.h>
 .PP
-.B
-#define assert(cond) if(cond);else _assert("cond")
+.B void assert(int cond)
 .PP
 .B
-void _assert(char* cond)
 .SH DESCRIPTION
 .I Assert
-is a preprocessor macro that
-(via
-.IR _assert )
-prints a message and calls
+is a function that prints the current process id and calls
 .I abort
 when
 .I cond
--- a/sys/src/libc/port/_assert.c
+++ b/sys/src/libc/port/_assert.c
@@ -1,13 +1,13 @@
 #include <u.h>
 #include <libc.h>
 
-void (*__assert)(char*);
+void (*__assert)(int);
 
 void
-_assert(char *s)
+assert(int cond)
 {
-	if(__assert)
-		(*__assert)(s);
-	fprint(2, "assert failed: %s\n", s);
+	if(cond)
+		return;
+	fprint(2, "pid %d: assert failed\n", getpid());
 	abort();
 }
--- a/sys/src/libthread/debug.c
+++ b/sys/src/libthread/debug.c
@@ -29,10 +29,3 @@
 	fmtprint(&f, "\n");
 	fmtfdflush(&f);
 }
-
-void
-_threadassert(char *s)
-{
-	_threadprint("%s: assertion failed", s);
-	abort();
-}

Re: [9front] [PATCH] Fix assert macro to not break on commas

[Blue-Maned_Hawk]

On 11/26/23 14:58, Kurt H Maier wrote:
> On Sun, Nov 26, 2023 at 12:31:52PM -0500, Blue-Maned_Hawk wrote:
>> On 11/25/23 21:22, Kurt H Maier wrote:
>>> Doing fancy shit with macros in places where you have the opportunity
>>> not to do fancy shit with macros is bad.
>>
>> This change is not fancy.  It's the bare minimum for things like this.
> 
> You still haven't even bothered to define "things like this" or make a
> single argument for having them.  This is the sort of dipshit behavior
> that got you kicked in IRC.

I was never asked to define the term.  If you'd like me to, please ask 
instead of being passive-agressive.  Assuming you would:  i refer to 
macros that intake an expression when i say that.

I've also never gotten kicked from the IRC, although at one point i do 
remember you extorting me into giving up private information under 
threat of ban.

Re: [9front] [PATCH] Fix assert macro to not break on commas

[Blue-Maned_Hawk]

On 11/26/23 13:13, ori@eigenstate.org wrote:
> Quoth Blue-Maned_Hawk <bluemanedhawk@gmail.com>:
>> I'm just new around here.
> 
> In general, we try pretty hard to avoid doing stuff
> in macros. There are places where it's unavoidable,
> but excluding ape, there's more #ifdef in ghostscript
> than in the rest of the system combined.
> 

I don't understand why you're bringing up ifdefs.  That's a completely 
different part of the preprocessor, unrelated to macros (though usable 
in combination with them).

What reason have y'all for avoiding macros?

Re: [9front] [PATCH] Fix assert macro to not break on commas

[Blue-Maned_Hawk]

On 11/26/23 13:59, Amavect wrote:
> Don't add needless abstraction for situations you don't have.

Is not it favorable to be proactive instead of reactive?

Re: [9front] [PATCH] Fix assert macro to not break on commas

[ori]

Quoth Blue-Maned_Hawk <bluemanedhawk@gmail.com>:
> On 11/26/23 13:13, ori@eigenstate.org wrote:
> > Quoth Blue-Maned_Hawk <bluemanedhawk@gmail.com>:
> >> I'm just new around here.
> > 
> > In general, we try pretty hard to avoid doing stuff
> > in macros. There are places where it's unavoidable,
> > but excluding ape, there's more #ifdef in ghostscript
> > than in the rest of the system combined.
> > 
> 
> I don't understand why you're bringing up ifdefs.  That's a completely 
> different part of the preprocessor, unrelated to macros (though usable 
> in combination with them).
> 
> What reason have y'all for avoiding macros?

Well, the fact that you need hacks like the one that started this
thread, for one; 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".

Re: [9front] [PATCH] Fix assert macro to not break on commas

[Blue-Maned_Hawk]

On 11/26/23 17:52, ori@eigenstate.org wrote:
> Quoth Blue-Maned_Hawk <bluemanedhawk@gmail.com>:
>> 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.

Re: [9front] [PATCH] Fix assert macro to not break on commas

[ori]

Quoth Blue-Maned_Hawk <bluemanedhawk@gmail.com>:
> On 11/26/23 17:52, ori@eigenstate.org wrote:
> > Quoth Blue-Maned_Hawk <bluemanedhawk@gmail.com>:
> >> 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");

Re: [9front] [PATCH] Fix assert macro to not break on commas

[Blue-Maned_Hawk]

On 11/26/23 19:00, ori@eigenstate.org wrote:
> Quoth Blue-Maned_Hawk <bluemanedhawk@gmail.com>:
>> On 11/26/23 17:52, ori@eigenstate.org wrote:
>>> Quoth Blue-Maned_Hawk <bluemanedhawk@gmail.com>:
>>>> 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.

Re: [9front] [PATCH] Fix assert macro to not break on commas

[ori]

Quoth Blue-Maned_Hawk <bluemanedhawk@gmail.com>:
> On 11/26/23 19:00, ori@eigenstate.org wrote:
> > Quoth Blue-Maned_Hawk <bluemanedhawk@gmail.com>:
> >> On 11/26/23 17:52, ori@eigenstate.org wrote:
> >>> Quoth Blue-Maned_Hawk <bluemanedhawk@gmail.com>:
> >>>> 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);

Re: [9front] [PATCH] Fix assert macro to not break on commas

[Amavect]

On Sun, Nov 26, 2023 at 4:47 PM Blue-Maned_Hawk <bluemanedhawk@gmail.com> wrote:
> Is not it favorable to be proactive instead of reactive?
Like all things, it depends.
A valid assert expression (per ISO C) not compiling is such a small
risk that being proactive isn't worth the added complexity.
If you had a program that you wanted to compile, I would have no objections.

Thanks,
Amavect

Re: [9front] [PATCH] Fix assert macro to not break on commas

[Dan Cross]

On Mon, Nov 27, 2023 at 10:40 AM <ori@eigenstate.org> wrote:
> Quoth Blue-Maned_Hawk <bluemanedhawk@gmail.com>:
> > On 11/26/23 19:00, ori@eigenstate.org wrote:
> > > Quoth Blue-Maned_Hawk <bluemanedhawk@gmail.com>:
> > >> On 11/26/23 17:52, ori@eigenstate.org wrote:
> > >>> Quoth Blue-Maned_Hawk <bluemanedhawk@gmail.com>:
> > >>>> 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);

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.

Re: [9front] [PATCH] Fix assert macro to not break on commas

[Blue-Maned_Hawk]

On 11/27/23 10:38, ori@eigenstate.org wrote:
> Quoth Blue-Maned_Hawk <bluemanedhawk@gmail.com>:
>> On 11/26/23 19:00, ori@eigenstate.org wrote:
>>> Quoth Blue-Maned_Hawk <bluemanedhawk@gmail.com>:
>>>> On 11/26/23 17:52, ori@eigenstate.org wrote:
>>>>> Quoth Blue-Maned_Hawk <bluemanedhawk@gmail.com>:
>>>>>> 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.

Re: [9front] [PATCH] Fix assert macro to not break on commas

[ori]

Quoth Blue-Maned_Hawk <bluemanedhawk@gmail.com>:
> 
> 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.


Sure I do:

	assert_msg((Thing){0, "foo"}.a, ==the message==> (Thing){1, "bar"}.b <===);

Or if you prefer:

	assert_msg((MsgWrapper){0, "bar"}.b, (CondWrapper){0, "meh"}.a);

Re: [9front] [PATCH] Fix assert macro to not break on commas

[Blue-Maned_Hawk]

I don't understand what you're referring to or what you are saying.

Re: [9front] [PATCH] Fix assert macro to not break on commas

[ori]

Quoth Blue-Maned_Hawk <bluemanedhawk@gmail.com>:
> I don't understand what you're referring to or what you are saying.

msg doesn't have to be a string literal, it can be an expression
containing commas.

Re: [9front] [PATCH] Fix assert macro to not break on commas

[Blue-Maned_Hawk]

On 11/27/23 19:34, ori@eigenstate.org wrote:
> Quoth Blue-Maned_Hawk <bluemanedhawk@gmail.com>:
>> I don't understand what you're referring to or what you are saying.
> 
> msg doesn't have to be a string literal, it can be an expression
> containing commas.
> 

After some fiddling, i have come up with this solution:

	#define _0assert_msg(...) (print(__VA_ARGS__), exits(__VA_ARGS__)))
	#define assert_msg(...) ((__VA_ARGS__) ? (void)0 : _0assert_msg

which can be invoked as assert_msg(cond)(msg); without any worry about 
misinterpreted commas.