On 06/27/14 01:47, Bill Paul wrote: > As I've said, the ASSERT() macros resolve to no-ops in some cases. If the > world does end, we want to be informed of it reliably, and we won't be if the > ASSERT()s turn to no-ops.
This argument is independent of any code. With the above paragraph you're arguing against the general existence (or use) of ASSERT() in edk2, and assert() in POSIX / SUS. http://pubs.opengroup.org/onlinepubs/9699919799/functions/assert.html The expressions one puts in ASSERT()s are invariants. They must hold under any circumstances. If an ASSERT() fails, then there's nothing else to do. There's no way to fail gracefully. At that point you can't check any other variables, any other conditions, because *everything* in your program could have been corrupted. There's no point in continuing after an ASSERT() fails. Semantically, there's no difference between an ASSERT() failing (and logging a debug message and spiraling into an infinite loop) and a compiled-out ASSERT() -- that would have failed -- after which the program decays to unforeseen behavior. The only difference is in debuggability. There's *also* no difference from the case when you try to handle a violated invariant. How do you know what *other* parts of the code and data you can still trust? For the code at hand, suppose you replace the ASSERT_EFI_ERROR (Status) macros with if (EFI_ERROR (Status)) {...}. Whatever you put in those blocks will be bogus. There's simply no way to write *anything* correct in there. If you propagate an error outwards, back to the protocol caller, that's a lie. You don't report internal corruption with EFI_WHATEVER, and allow the clueless caller (whose memory might have been trampled over) to happily try alternatives, try to save files, clean up, and exit in a controlled manner. If the condition is not of this nature (ie. it is not an invariant), then don't put it in an ASSERT(); check it with an "if". For the code at hand, those conditions are invariants. What we have here is no different from asserting that 2+2 equals 4. Would you check that with an if? And would you try to handle the error? ASSERT()s don't catch operational circumstances, they catch programmer thinkos. Once you're fairly sure that there are no more thinkos in the code (for example because you proved the code), you disable the ASSERT()s, purely for performance and size reasons. (Corollary: if you don't care about those above all, never disable ASSERT()s.) I *can* accept a general argument against ASSERT(). In medical software, industrial machinery, space exploration. In those areas, you probably rely on a different development attitude. Like, formal methods. In those areas you handle programmer thinkos differently. You build the entire system so that it distrusts itself. However, - This is probably overkill for firmware development. - Even if it's not, please recognize that your argument against ASSERT()s is a general one, independent of any code. > Fine. I don't care how you deal with it, but could you please just do us all > a > favor and get rid of the warnings? Sure, I think patches have been posted already (in the starter msg of this thread). Done ranting for today! :) Cheers Laszlo ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
