Jan 31, 2015

[Defensive Programming]

Reading notes of
John Lakos "Defensive Programming Done Right, Part I"
John Lakos "Defensive Programming Done Right, Part II"
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4075.pdf

Design by Contract:

1. What it does
2. What it returns
3. Essential Behavior
4. Undefined behavior unless...
5. Note that


Verification:
1. Preconditions
  RTFM read the fxcking manual
  Assert

2. Postconditions
  Component-level test drivers

3. Invariants
  Assert invatiants in the destructor


-----
4 things:
  1. component level testing
  2. peer review
  3. static analysis tool
  4. DP
-----

Why do we assert only in safe debug mode?

Put assert on postconditions? Time to confirm th test.

Must the code itself _preserve_ invariants even if one or more preconditions of a contract are violated?
NO!!!

-----

What is DP?
Redundant code that provides runtime checks to detect and report
(but not 'handle' or hide) defects in software.

DP good or bad?
Both.
add overhead, but help idenfity defects.

What are we defending against?
1. Bugs in software we use. (Not DP!)
2. Bugs we introduced. (No...)
3. Misuse by our clients. (YES!!)
-----

Fat interface / bad / not proper inheritance
Large interface / bad / not minimal/primitive
Wide contract / bad / No preconditions

------
Narrow contracts imply UB!

Assert inside the funciton. Don't just return 0/false/none

------
Should setXXX mem_fn return status?
NO!!!!

Returning status implies wide contract.

Wide contracts prevent defending against
  such errors in _any_ build mode.


Beware!! assert is expansive!!


Narror contract only check in debug mode.
Wide contract checks by every call!
------

Preconditions _always_ imply postconditions.

**
If a function cannot satisfy it's contract,
it must _not_ return normally.

------
abort() should be considered a viable alternative to
throw in virtually all cases(if exceptions are disabled)

-----
**
Good library components are exception-neutral! (via RAII)

-----
**
What should happen when the behavior is undefined?
Should what happens be part of the component-level contract?
  NO!! Otherwise it would be a behavior contract.
  Do not document UB!
  Otherwise it's not UB anymore!
-----

-----------------------------------
Implementing defensive checks.


---
What should happen if the client misuses library code??

Ask library component to warn us?

1. Document
2. Detect UB
3. Detect all UB?
4. How much CPU time should spend trying to detect misuse of library code?

a. Terminate the program
b. Thrown exception
  c. Save client work before terminate
  d. log error
  e. sent back to programming msg?


---
Plan(Part 1):
Provide 3 kinds of assert macros for library writer to use.

Assert_Opt(Expr)  < 5% CPU

Assert(Expr)  5% ~ 20% CPU

Assert_Safe(Expr) > 20%

---
Plan(Part 2)
Provide a global callback facility.

using handler = void (*)(const char* text, const char* file, int line)
// move the parameters into a single Struct type..


1. failAbort // print and terminate
2. failThrow // wrap into std::logic_error
3. failSleep // print to stderr and spin/sleep

---

e.g
void fun()
{
  auto result = library_func(); //library_func implement assert
}


---
Rule of thumb(guideline):
1. inline functions use Assert_Safe
2. Non-inline functions use Assert

---
Hard vs. Soft UB:
2 separate notion of UB.

1. Language UB (Hard UB)

2. Library UB (Soft UB)

With Library(i.e Soft) UB, (a contract violation)
nothing dire has happened yet, but it could easily lead to Language UB.

Soft UB is relative:
  . not privy to the implementation, might lead to Hard UB.
  . Contract violation can remain Soft UB.


--------
Compile macro build mode.

--------

Mixed-Mode Assertion Build

1. ABI incompatibility.
No.
  .all assertion-level modes musy be ABI compatible.
  .Only permitted side-effect is to invoke the failure handler.

2. Violating the ODR. Yes
-----------

c++11 noexcept: and C++14 follow this standard.
1. Use only for move constructors and move assignment
2. Use whereever there is a wide contract, and the operation must never throw.
3. Use whereever the operation must never throw in contract.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.