Other Aliaslog_open, log_close, log_reset, log_flush, log_printf, log_vprintf, log_puts
LIBRARIESDebug Library (-ldebug)
int log_open(const char *logfile, int level, int flags);
int log_printf(int level, const char *fmt, ...);
int log_vprintf(int level, const char *fmt, va_list ap);
int log_putc(int level, int c);
int log_puts(int level, const char *str);
DESCRIPTIONlog_open() initializes the logging system. The filename of the file to which messages are logged should be specified by logfile, or NULL if messages should be printed to the console. The values for level and flags are given in the next section.
From version 0.4.1 onwards the debug library also supports logging to syslog instead of a file. Instead of specifying a file, just specify a string in the form ident.facility, where ident is a string which will be prepended to each syslog message and is usually the program name. The facility should be the facility to which messages should be logged.
log_close() flushes all pending messages, and closes the file descriptor of the log file (if any).
log_reset() reinitializes the logging system. If any files are currently opened for writing, it will be closed and reopened. This is useful if you need to rotate log files.
log_flush() flushes all pending messages (if any).
log_printf() and log_vprintf() are replacements for printf(3) and vprintf(3) respectively.
log_putc() will log a single character. This is the equivalent of putchar(3).
log_puts() will log a string. It is the equivalent of puts(3), except that is does not append a trailing newline.
PARAMETERSThis section lists the parameters used to set the values of level and flags.
levelThis determines the importance of the message. The levels are, in order of decreasing verbosity:
- verbose debug messages
- debug messages
- informational messages
- normal, but significant, conditions
- warning conditions
- error conditions
- no messages are printed
The level argument to log_printf(), log_vprintf(), log_putc(), and log_puts() specify the level at which the message should be printed. It does not make sense to specify LOG_QUIET to these functions.
The level argument to log_open() sets the verbosity of the program. Any messages printed with a level higher (more verbose) than that specified to the log_open() function, will be discarded.
flagsThe flags argument to log_open() is an OR of any of these:
- If this flag is specified and messages are printed to the console (i.e. no log file is specified), messages will be printed in different colors, depending on their log level.
- If this flag is specified, the function in which the print function was called would be printed in addition to the filename and line number.
- If this flag is specified, only messages with a level higher or equal to (i.e. more or as verbose) LOG_DEBUG will be printed in color and with file, line number, and (if necessary), the function.
- If this flag is specified, messages would be buffered and duplicate lines would not be printed. Instead, the first message would be printed, followed by a line describing the number of times the message repeated. This is a great way to prevent flooding, but unfortunately it has the side effect of always being one statement behind.
- If specified, the rate at which messages are printed would be limited in order to avoid flooding. This feature have not been implemented yet, and is currently ignored.
RETURN VALUEAll functions except log_close() return 0 if successful, -1 if some error occurred. Check errno to see which error occurred.
If log_reset() or log_open() fails, behaviour is undefined and it should be assumed that no logging is possible.
The log_close() function returns no value.
NOTESIf this routines are combined with the memory routines, care should be taken to call open and close functions in the right order. The correct order is as follows:
mem_open (NULL); log_open (NULL,LOG_NORMAL,LOG_HAVE_COLORS | LOG_PRINT_FUNCTION); atexit (mem_close); atexit (log_close);
Of course, atexit(3) should only be used if the program will not forked.
None of the libdebug routines are thread-safe. I'm not planning to change this either! For more information, please see http://threading.2038bug.com/
AUTHORWritten by Abraham vd Merwe <[email protected]>