|Title||MPS contains asserts that don't indicate which problem occurred|
|Assigned user||Richard Kistruck|
|Description||MPS contains asserts that don't indicate which problem occurred. Often this is because they have several failure cases combined together. Replace these, with each failure case in a separate assert. Note that much of the MPS programmer interface, eg. for protocol violations, is done with asserts.|
G: please split up all "OR" assertions; they're just annoying.
My understanding of this job is to fix situations where multiple _failure_ cases are trapped by one assert. If it fires, you have to use the debugger to peek at variables, in order to see which failure case it happened to be.
[So the earlier description was wrong: asserts with || should not be changed (they have only one failure case); asserts with && have two failure cases, and should be split into two asserts. Description corrected. RHSK 2005-09-30]
grep -l '&&' mps/code/* | wc says there are 57 files with &&. Where they are in an assert statement, splitting is easy. Where they are in a macro it may be harder. For example, in check.h:
#define CHECKT(type, val) ((val) != NULL && (val)->sig == type ## Sig)
Which files? Look through all 57 candidates. These have simple asserts:
These have && in macros (eg. CHECKT) used in hundreds of asserts. That's much harder to fix:
Much of the interface checking is done via these macros. It may be that the real customer requirement is more helpful reporting of interface protocol violations. I will investigate, and if so, create a new p4 job.
|Evidence||Raw notes from Configura workshop <|
|Created by||Richard Kistruck|
|Created on||2005-03-10 03:35:27|
|Last modified by||Gareth Rees|
|Last modified on||2014-06-13 15:52:50|
|History||2005-03-10 RHSK create|
2005-09-29 RHSK analyse
2005-09-30 RHSK changed description: replace inaccurate "several clauses || (ORed) together" with "several failure cases combined together".
|186577||closed||2014-06-13 15:52:50||Gareth Rees||Some assertions with && crept back in. Split them up so that we get as much information as possible from an assertion failure.|
|155170||closed||2005-09-30 10:50:48||Richard Kistruck||split-asserts: where an AVER or CHECKL has two failure modes combined
with &&, split it into two AVERs or CHECKLs.