On 09/05/2017 09:50 PM, Eric Blake wrote: > On 08/24/2017 02:51 AM, Markus Armbruster wrote: >> Eric Blake <[email protected]> writes: >> >>> On 08/22/2017 06:19 AM, Halil Pasic wrote: >>> >>>> OTOH I do think this is to some degree institutionalizing a bad practice >>>> (you say we do not want to do that, but IMHO refusing to build with >>>> NDEBUG makes only sense if we want to alter the semantic of assert so >>>> that once bad becomes acceptable). I can live with that, but I'm not >>>> happy about it. Have we considered rolling our own construct which is >>>> designed to exhibit the properties we desire? >>> > >>> >>> I'd prefer that if we are going to introduce our own construct that >>> always evaluates side effects, and only has a compile-time switch on >>> whether to abort() or (foolishly) plow on, that we name it something >>> without 'assert' in the name, so that reviewers don't have to be >>> confused about remembering which variant evaluates side effects. Maybe: >>> >>> q_verify(cond) >>> > >> >> I vote for frying bigger fish. >> >> I also vote for using standard C when standard C is servicable. > > So if it were up to me alone, the answer is: > > I'm NOT going to add any new construct (whether spelled q_verify() or > otherwise), and will merely document in the commit message that we > discussed this as an alternative (so someone who wants to disable #error > can get a git history of what went into the decision). > > Also, it sounds like we want to keep it #error, not #warn. > > But if anyone else has strong opinions before we promote this from RFC > to actual patch, I'm still interested in your arguments. >
I'm fine with this outcome: it is a minimal solution to a real problem. My initiative was a kind of bike-shedding: any devel with enough exposure to qemu to matter will learn soon enough that the assert macro is special in this project. Regards, Halil
signature.asc
Description: OpenPGP digital signature
