[olsr-dev] Re: Die "%m", die

[Thomas Lopatic]

Hey Bernd,

First of all, thanks for your thorough code review efforts! We greatly
appreciate it that somebody takes the time to clean up the code of olsrd.

[...]

> My strategic problem with the error reporting actually is: I can't see
> in a simple way, what should be reported when and via which means and
> how should it be configurable (at compile-time and at run-time).
> There is perror() at some places, there is the OLSR_FPRINTF macro, there
> is syslog() and in different combination at different places.
> 
> Perhaps Andreas T. or Thomas L. can put some light on this (and I'm not
> so interested in the history but more on the goal or features)?!

Erm, there isn't any goal behind the diversity of error reporting
mechanisms in olsrd, there's only history. :-) So, I agree that making
the error reporting use the same function in all places is a good idea.

> Im my simple world, a function like "void olsr_error(int level, const
> char * const format, ...);"[0] should hide all the magic (probalby with
> configuration variables) if perror() should be used, syslog(), or
> whatever and how the messages should be filtered.

The OLSR_PRINTF macro is in place so that, on platforms that do not have
much CPU power, we can easily remove things like the following from the
code:

OLSR_PRINTF(3, "The result of the really expensive debug operation is
%d.\n", really_expensive());

At a debug level below 3 this wouldn't output anything, but
really_expensive() would still be calculated, which puts a burden on
platforms with weak CPUs.

We can solve this problem by simply switching off debugging completely
for those platforms:

#define OLSR_PRINTF()

So, as long as the function is wrapped into a macro, I think that your
suggestion absolutely makes sense. I like a simple world. As Elektra
likes to put it: Usually you get from a primitive solution to a
complicated solution and, finally, from there to a simple solution.

Andreas - did I miss anything?

-Thomas