* [9front] [PATCH] Fix assert macro to not break on commas @ 2023-11-22 23:11 Blue-Maned_Hawk 2023-11-23 4:20 ` Jacob Moody 2023-11-26 22:36 ` ori 0 siblings, 2 replies; 33+ messages in thread From: Blue-Maned_Hawk @ 2023-11-22 23:11 UTC (permalink / raw) To: 9front 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) ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] [PATCH] Fix assert macro to not break on commas 2023-11-22 23:11 [9front] [PATCH] Fix assert macro to not break on commas Blue-Maned_Hawk @ 2023-11-23 4:20 ` Jacob Moody 2023-11-25 0:27 ` Blue-Maned_Hawk 2023-11-26 22:36 ` ori 1 sibling, 1 reply; 33+ messages in thread From: Jacob Moody @ 2023-11-23 4:20 UTC (permalink / raw) To: 9front 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] [PATCH] Fix assert macro to not break on commas 2023-11-23 4:20 ` Jacob Moody @ 2023-11-25 0:27 ` Blue-Maned_Hawk 2023-11-25 1:09 ` Jacob Moody ` (3 more replies) 0 siblings, 4 replies; 33+ messages in thread From: Blue-Maned_Hawk @ 2023-11-25 0:27 UTC (permalink / raw) To: 9front 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? ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] [PATCH] Fix assert macro to not break on commas 2023-11-25 0:27 ` Blue-Maned_Hawk @ 2023-11-25 1:09 ` Jacob Moody 2023-11-25 4:34 ` ori ` (2 subsequent siblings) 3 siblings, 0 replies; 33+ messages in thread From: Jacob Moody @ 2023-11-25 1:09 UTC (permalink / raw) To: 9front 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] [PATCH] Fix assert macro to not break on commas 2023-11-25 0:27 ` Blue-Maned_Hawk 2023-11-25 1:09 ` Jacob Moody @ 2023-11-25 4:34 ` ori 2023-11-25 12:09 ` Blue-Maned_Hawk 2023-11-25 4:49 ` ori 2023-11-26 18:59 ` Amavect 3 siblings, 1 reply; 33+ messages in thread From: ori @ 2023-11-25 4:34 UTC (permalink / raw) To: 9front 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)) ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] [PATCH] Fix assert macro to not break on commas 2023-11-25 4:34 ` ori @ 2023-11-25 12:09 ` Blue-Maned_Hawk 2023-11-25 18:46 ` Kurt H Maier 0 siblings, 1 reply; 33+ messages in thread From: Blue-Maned_Hawk @ 2023-11-25 12:09 UTC (permalink / raw) To: 9front 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); ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] [PATCH] Fix assert macro to not break on commas 2023-11-25 12:09 ` Blue-Maned_Hawk @ 2023-11-25 18:46 ` Kurt H Maier 2023-11-25 20:06 ` Steve Simon 0 siblings, 1 reply; 33+ messages in thread From: Kurt H Maier @ 2023-11-25 18:46 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] [PATCH] Fix assert macro to not break on commas 2023-11-25 18:46 ` Kurt H Maier @ 2023-11-25 20:06 ` Steve Simon 2023-11-25 20:39 ` Dan Cross 0 siblings, 1 reply; 33+ messages in thread From: Steve Simon @ 2023-11-25 20:06 UTC (permalink / raw) To: 9front 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] [PATCH] Fix assert macro to not break on commas 2023-11-25 20:06 ` Steve Simon @ 2023-11-25 20:39 ` Dan Cross 2023-11-25 22:47 ` Steve Simon 2023-11-26 2:22 ` Kurt H Maier 0 siblings, 2 replies; 33+ messages in thread From: Dan Cross @ 2023-11-25 20:39 UTC (permalink / raw) To: 9front 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] [PATCH] Fix assert macro to not break on commas 2023-11-25 20:39 ` Dan Cross @ 2023-11-25 22:47 ` Steve Simon 2023-11-26 2:22 ` Kurt H Maier 1 sibling, 0 replies; 33+ messages in thread From: Steve Simon @ 2023-11-25 22:47 UTC (permalink / raw) To: 9front 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] [PATCH] Fix assert macro to not break on commas 2023-11-25 20:39 ` Dan Cross 2023-11-25 22:47 ` Steve Simon @ 2023-11-26 2:22 ` Kurt H Maier 2023-11-26 17:31 ` Blue-Maned_Hawk 1 sibling, 1 reply; 33+ messages in thread From: Kurt H Maier @ 2023-11-26 2:22 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] [PATCH] Fix assert macro to not break on commas 2023-11-26 2:22 ` Kurt H Maier @ 2023-11-26 17:31 ` Blue-Maned_Hawk 2023-11-26 18:13 ` ori 2023-11-26 19:58 ` Kurt H Maier 0 siblings, 2 replies; 33+ messages in thread From: Blue-Maned_Hawk @ 2023-11-26 17:31 UTC (permalink / raw) To: 9front 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] [PATCH] Fix assert macro to not break on commas 2023-11-26 17:31 ` Blue-Maned_Hawk @ 2023-11-26 18:13 ` ori 2023-11-26 22:39 ` Blue-Maned_Hawk 2023-11-26 19:58 ` Kurt H Maier 1 sibling, 1 reply; 33+ messages in thread From: ori @ 2023-11-26 18:13 UTC (permalink / raw) To: 9front 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] [PATCH] Fix assert macro to not break on commas 2023-11-26 18:13 ` ori @ 2023-11-26 22:39 ` Blue-Maned_Hawk 2023-11-26 22:52 ` ori 0 siblings, 1 reply; 33+ messages in thread From: Blue-Maned_Hawk @ 2023-11-26 22:39 UTC (permalink / raw) To: 9front 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? ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] [PATCH] Fix assert macro to not break on commas 2023-11-26 22:39 ` Blue-Maned_Hawk @ 2023-11-26 22:52 ` ori 2023-11-26 23:30 ` Blue-Maned_Hawk 0 siblings, 1 reply; 33+ messages in thread From: ori @ 2023-11-26 22:52 UTC (permalink / raw) To: 9front 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". ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] [PATCH] Fix assert macro to not break on commas 2023-11-26 22:52 ` ori @ 2023-11-26 23:30 ` Blue-Maned_Hawk 2023-11-27 0:00 ` ori 0 siblings, 1 reply; 33+ messages in thread From: Blue-Maned_Hawk @ 2023-11-26 23:30 UTC (permalink / raw) To: 9front 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] [PATCH] Fix assert macro to not break on commas 2023-11-26 23:30 ` Blue-Maned_Hawk @ 2023-11-27 0:00 ` ori 2023-11-27 11:20 ` Blue-Maned_Hawk 0 siblings, 1 reply; 33+ messages in thread From: ori @ 2023-11-27 0:00 UTC (permalink / raw) To: 9front 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"); ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] [PATCH] Fix assert macro to not break on commas 2023-11-27 0:00 ` ori @ 2023-11-27 11:20 ` Blue-Maned_Hawk 2023-11-27 15:38 ` ori 0 siblings, 1 reply; 33+ messages in thread From: Blue-Maned_Hawk @ 2023-11-27 11:20 UTC (permalink / raw) To: 9front 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] [PATCH] Fix assert macro to not break on commas 2023-11-27 11:20 ` Blue-Maned_Hawk @ 2023-11-27 15:38 ` ori 2023-11-27 15:59 ` Dan Cross 2023-11-27 22:21 ` Blue-Maned_Hawk 0 siblings, 2 replies; 33+ messages in thread From: ori @ 2023-11-27 15:38 UTC (permalink / raw) To: 9front 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); ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] [PATCH] Fix assert macro to not break on commas 2023-11-27 15:38 ` ori @ 2023-11-27 15:59 ` Dan Cross 2023-11-27 22:21 ` Blue-Maned_Hawk 1 sibling, 0 replies; 33+ messages in thread From: Dan Cross @ 2023-11-27 15:59 UTC (permalink / raw) To: 9front 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] [PATCH] Fix assert macro to not break on commas 2023-11-27 15:38 ` ori 2023-11-27 15:59 ` Dan Cross @ 2023-11-27 22:21 ` Blue-Maned_Hawk 2023-11-27 23:59 ` ori 1 sibling, 1 reply; 33+ messages in thread From: Blue-Maned_Hawk @ 2023-11-27 22:21 UTC (permalink / raw) To: 9front 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] [PATCH] Fix assert macro to not break on commas 2023-11-27 22:21 ` Blue-Maned_Hawk @ 2023-11-27 23:59 ` ori 2023-11-28 0:30 ` Blue-Maned_Hawk 0 siblings, 1 reply; 33+ messages in thread From: ori @ 2023-11-27 23:59 UTC (permalink / raw) To: 9front 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); ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] [PATCH] Fix assert macro to not break on commas 2023-11-27 23:59 ` ori @ 2023-11-28 0:30 ` Blue-Maned_Hawk 2023-11-28 0:34 ` ori 0 siblings, 1 reply; 33+ messages in thread From: Blue-Maned_Hawk @ 2023-11-28 0:30 UTC (permalink / raw) To: 9front I don't understand what you're referring to or what you are saying. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] [PATCH] Fix assert macro to not break on commas 2023-11-28 0:30 ` Blue-Maned_Hawk @ 2023-11-28 0:34 ` ori 2023-11-29 9:14 ` Blue-Maned_Hawk 0 siblings, 1 reply; 33+ messages in thread From: ori @ 2023-11-28 0:34 UTC (permalink / raw) To: 9front 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] [PATCH] Fix assert macro to not break on commas 2023-11-28 0:34 ` ori @ 2023-11-29 9:14 ` Blue-Maned_Hawk 0 siblings, 0 replies; 33+ messages in thread From: Blue-Maned_Hawk @ 2023-11-29 9:14 UTC (permalink / raw) To: 9front 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] [PATCH] Fix assert macro to not break on commas 2023-11-26 17:31 ` Blue-Maned_Hawk 2023-11-26 18:13 ` ori @ 2023-11-26 19:58 ` Kurt H Maier 2023-11-26 22:37 ` Blue-Maned_Hawk 1 sibling, 1 reply; 33+ messages in thread From: Kurt H Maier @ 2023-11-26 19:58 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] [PATCH] Fix assert macro to not break on commas 2023-11-26 19:58 ` Kurt H Maier @ 2023-11-26 22:37 ` Blue-Maned_Hawk 0 siblings, 0 replies; 33+ messages in thread From: Blue-Maned_Hawk @ 2023-11-26 22:37 UTC (permalink / raw) To: 9front 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] [PATCH] Fix assert macro to not break on commas 2023-11-25 0:27 ` Blue-Maned_Hawk 2023-11-25 1:09 ` Jacob Moody 2023-11-25 4:34 ` ori @ 2023-11-25 4:49 ` ori 2023-11-26 18:59 ` Amavect 3 siblings, 0 replies; 33+ messages in thread From: ori @ 2023-11-25 4:49 UTC (permalink / raw) To: 9front 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] [PATCH] Fix assert macro to not break on commas 2023-11-25 0:27 ` Blue-Maned_Hawk ` (2 preceding siblings ...) 2023-11-25 4:49 ` ori @ 2023-11-26 18:59 ` Amavect [not found] ` <7025e6e9-fca5-4648-aaea-a80260c35739@sirjofri.de> 2023-11-26 22:41 ` Blue-Maned_Hawk 3 siblings, 2 replies; 33+ messages in thread From: Amavect @ 2023-11-26 18:59 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
[parent not found: <7025e6e9-fca5-4648-aaea-a80260c35739@sirjofri.de>]
* Re: [9front] [PATCH] Fix assert macro to not break on commas [not found] ` <7025e6e9-fca5-4648-aaea-a80260c35739@sirjofri.de> @ 2023-11-26 21:11 ` sirjofri 0 siblings, 0 replies; 33+ messages in thread From: sirjofri @ 2023-11-26 21:11 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] [PATCH] Fix assert macro to not break on commas 2023-11-26 18:59 ` Amavect [not found] ` <7025e6e9-fca5-4648-aaea-a80260c35739@sirjofri.de> @ 2023-11-26 22:41 ` Blue-Maned_Hawk 2023-11-27 15:44 ` Amavect 1 sibling, 1 reply; 33+ messages in thread From: Blue-Maned_Hawk @ 2023-11-26 22:41 UTC (permalink / raw) To: 9front 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? ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] [PATCH] Fix assert macro to not break on commas 2023-11-26 22:41 ` Blue-Maned_Hawk @ 2023-11-27 15:44 ` Amavect 0 siblings, 0 replies; 33+ messages in thread From: Amavect @ 2023-11-27 15:44 UTC (permalink / raw) To: 9front 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [9front] [PATCH] Fix assert macro to not break on commas 2023-11-22 23:11 [9front] [PATCH] Fix assert macro to not break on commas Blue-Maned_Hawk 2023-11-23 4:20 ` Jacob Moody @ 2023-11-26 22:36 ` ori 1 sibling, 0 replies; 33+ messages in thread From: ori @ 2023-11-26 22:36 UTC (permalink / raw) To: 9front 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(); -} ^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2023-11-29 9:15 UTC | newest] Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-11-22 23:11 [9front] [PATCH] Fix assert macro to not break on commas Blue-Maned_Hawk 2023-11-23 4:20 ` Jacob Moody 2023-11-25 0:27 ` Blue-Maned_Hawk 2023-11-25 1:09 ` Jacob Moody 2023-11-25 4:34 ` ori 2023-11-25 12:09 ` Blue-Maned_Hawk 2023-11-25 18:46 ` Kurt H Maier 2023-11-25 20:06 ` Steve Simon 2023-11-25 20:39 ` Dan Cross 2023-11-25 22:47 ` Steve Simon 2023-11-26 2:22 ` Kurt H Maier 2023-11-26 17:31 ` Blue-Maned_Hawk 2023-11-26 18:13 ` ori 2023-11-26 22:39 ` Blue-Maned_Hawk 2023-11-26 22:52 ` ori 2023-11-26 23:30 ` Blue-Maned_Hawk 2023-11-27 0:00 ` ori 2023-11-27 11:20 ` Blue-Maned_Hawk 2023-11-27 15:38 ` ori 2023-11-27 15:59 ` Dan Cross 2023-11-27 22:21 ` Blue-Maned_Hawk 2023-11-27 23:59 ` ori 2023-11-28 0:30 ` Blue-Maned_Hawk 2023-11-28 0:34 ` ori 2023-11-29 9:14 ` Blue-Maned_Hawk 2023-11-26 19:58 ` Kurt H Maier 2023-11-26 22:37 ` Blue-Maned_Hawk 2023-11-25 4:49 ` ori 2023-11-26 18:59 ` Amavect [not found] ` <7025e6e9-fca5-4648-aaea-a80260c35739@sirjofri.de> 2023-11-26 21:11 ` sirjofri 2023-11-26 22:41 ` Blue-Maned_Hawk 2023-11-27 15:44 ` Amavect 2023-11-26 22:36 ` ori
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).