Re: How to implement diagnostic messages?

On 9/8/2011 6:58 AM, Rui Maciel wrote:
In some applications it's useful to have, at least in the development
stages, a way to output diagnostic messages in order to help developers
check what's happening under the hood. Yet, although this can be useful and
in some times even invaluable, there isn't much information on what are
considered to be good practices regarding the implementation of diagnostic
messages.

With this in mind, what are your views on how to implement diagnostic
messages? Are simple outputs to stderr enough or are there better ways to
handle this?


the great problems with stderr:
the messages are not recorded anywhere (can't look over them in more detail later);
in graphical and/or GUI applications, stdout and stderr tend to go nowhere, so anything sent there is not visible.

in my own apps, I tended to just use printf a lot.
eventually, I made a macro which hooked printf to one of my own functions, and mostly ended up just redirecting its output to a log file and to an in-program console (in addition to stdout).

this way, for an app, one can typically see messages in-program, or if there is too much output, go and look over the recorded log-file.


later, I also added a "dbgprintf" function, which also accepts an integer parameter giving its "debug level" (IIRC, number+flags), but have not ended up widely using it.

the idea here would be that dbgprintf would also redirect to the console, and to the log file, but that the debug-level could be used to cull lower-priority messages.

IIRC, level 0 was equivalent to a printf, and 1..N (limit not set, maybe 7 or 15) indicate progressively lower-priority messages.

a message with a greater debug-level than the present debug-level will simply be discarded (neither shown in console, nor logged).

an unaddressed issue is "where" the messages are from, which often matters a lot more than some global "debug level" (one tends to care a lot more about messages from the components they are debugging, without having to necessarily see a mountain of messages for whatever else is going on, like other components loading/saving files, messages from the sound mixer, ...).


the current practice, for the most part, is a bit less organized, and mostly involves manually adding/commenting/uncommenting printf calls.

or such...
.

Relevant Pages

  • Re: Recent problems with -current on alpha...
    ... syscons console initialization depends on this. ... I hade a printf() in make_dev. ... message buffer is not initialized until later, ...
    (freebsd-current)
  • Re: Create a console app under EmbeddedVC4, and debug it
    ... don't typically use printf, so I don't know if that will work or not. ... > from Embedded VC4. ... > I understand that WinMain is a console application, however, I really want ... > since we have some existing code that we want to compile it. ...
    (microsoft.public.windowsce.embedded)
  • Re: mtx_lock_do_what_i_mean()
    ... kernel from anything to which we have a TTY attached. ... at printf() as a means to write to the message buffer only. ... and 2) something you can do by going through the TTY ... The fact that currently the console is used by both does ...
    (freebsd-arch)
  • Re: Machine wedges solid after one serial-port source-line addition...
    ... (My original hack-patches without ... All it does is notify the console whenever a serial port DCD ... You are calling printf() from a fast interrupt handler. ...
    (freebsd-hackers)