[En-Nut-Discussion] NUT_OSDEBUG to stderr instead of stdout

[Harald Kipp]

Hi Thiago,

Thiago A. Corrêa wrote:
>    Many applications and samples uses stdout for things other than
> debug or trace. I would like to suggest that we change the code inside
> Nut/OS to use fprintf(stderr) and have apps who would like to monitor
> that data to assign a device to stderr instead of stdout. This way
> most applications can be debugged with NUT_OSDEBUG or use the trace
> functionality.

Initially printf() was used, some of us may even remember NutPrintFormat().

Later this had been changed to fprintf(__xxx_trs, ...) with a special
init call NutTracexxx() to specify the output stream. This adds not only
more code, but also introduces extra work for the stressed bug hunting
programmer. As a result, printf() re-appeared in many parts of the code.

The disadvantage you see is in fact an advantage in many situations.
Because stdout is already available, it can be used directly without any
additional effort (e.g. assigning stderr) and the mixture of normal and
debug output is an additional benefit.

Why does the application use printf instead of fprintf?

So far, that's the disclaimer. ;-)

Of course I do understand the problem. Beside the fact that stderr is
"more natural" stream for debug output, I wouldn't want to give up
stdout per se.

The "fits-everywhere-hyper-standard-answer" is ... though I hate to say
it again: Let's make it configurable. Sigh!

At least the newly added EARLY_STDIO_DEV should get a XXX_STREAM
companion, so verbose output during initialization is not limited to stdout.

Harald