Re: asserts

From: Patrick Lam (plam@plam.lcs.mit.edu)
Date: Wed Apr 17 2002 - 23:13:28 EDT

  • Next message: Andrew Dunbar: "Re: asserts"

    On Thu, Apr 18, 2002 at 04:52:42AM +0200, Mike Nordell wrote:
    > Add asserts wherever applicable. Add asserts to the "impossible" value,
    > since that value _is_ to be impossible. Add asserts to apparently impossible
    > places. Add a debug-only function IsValidReadAddress(const void*); and
    > IsValidWriteAddress(void*); For Win32 that would be mapped to IsBadReadPtr &
    > co., and for *nix I'd expect something similar to be present (even if
    > implemented in terms of a segv signal handler). But for debug mode, add
    > whatever you can to verify parameters, variables and just about anything.
    > F.ex. I can mention a BOOL (whatever we called them back then) that could
    > gain the value 0xcc when using a good compiler. Nowadays bool's aren't that
    > bad, but you get the drift.

    For the sake of discussion, I'd like to mention valgrind. Valgrind is
    an excellent Linux tool which checks *all* memory reads and writes for
    validity and detects memory leaks (the technology is really cool too).
    This subsumes IsValidRead/WriteAddress, although we don't always run
    Abi with valgrind.

    I claim that excessive asserting (I would not assert BOOL \in {true, false})
    is bad style, because it makes program logic hard to follow. Surprising
    asserts should be there (like when we think that something might happen
    to be false) but not unsurprising asserts.

    pat



    This archive was generated by hypermail 2.1.4 : Wed Apr 17 2002 - 23:14:19 EDT