Completion of error handling

[elfring]

Would you like to add more error handling for return values from functions like the following?

• malloc ⇒ main
• printf ⇒ Trace::TracePacketUncond

[smurfix]

Quite frankly, at the moment I'm much more concerned with getting the non-error features working (like bus monitoring or the all-ACK mode, see other bugs, or switching away from libpth so that we can use valgrind to check for memory leaks) than with handling error cases wich ought to be fatal anyway.

In particular, a random small malloc() is never going to fail by returning NULL these days. It's going to fail by stalling the program an inordinate amount of time, then the kernel's out-of-memory handler will kill some program (hopefully the one responsible for the memory shortage). So we might as well segfault anyway.

That being said, accurate error reporting certainly is one of the weak points of knxd. So if you want to replace all those random printf calls with reasonable trace calls and/or error logging, go right ahead.

[elfring]

A null pointer because of an allocation failure might appear unlikely. I suggest to avoid ignorance of return values a bit more. Would you like to detect every error situation as early as possible?

[smurfix]

Error handling is certainly one of the weak areas of knxd. Specifically, the current roughly-layer-based bitmask values should be cleaned up and augmented with some kind of severity.

Layers should probably be:

0 byte-level data trace to devices / clients 1 message-level data trace to devices / clients 2 state changes within a device / client connection 3 new / dead connections, connection's mode changes, et al. 4 Layer2 API (class interface of the device / connection) (implemented as a named filter) 5 Layer3 interchange (one message per datagram-to-be-distributed)

Levels: standard syslog, i.e. debug info notice warn error fatal.