Design Decisions

The severity of undefined behavior (UB) is sometimes less than error

• UB that is common and likely to work => portability
• UB that is uncommon, suspicious or avoidable, but likely to work => warning
• UB that is unlikely to work => error

Reasons:

1. "char* p = 0x400;" causes UB, but when writing software for hardware there might be no alternative way for doing it.
2. Standard is not absolutely clear weather calling static member function via null pointer is UB or not. ​http://stackoverflow.com/questions/2474018/when-does-invoking-a-member-function-on-a-null-instance-result-in-undefined-beha

Reasons against:

1. The only solid base for the correctness of the code is the standards.
2. Dividing the UB into different groups is based on opinions, not on any facts.

Use --option=value format for long command line options that take value in documentation

Reasons:

1. It is the GNU standard and also followed by many programs: ​http://www.gnu.org/s/hello/manual/libc/Argument-Syntax.html
2. For usability, we should use one style everywhere
3. We already use it everywhere

see also: CodingStyle