Re: glib's g_logv 1024 byte maximum character array

[Magnus Bergman <magnusbe algonet se>]

On Tue, 22 Jul 2003 17:07:14 +0100
martyn 2 russell bt com wrote:

> > > Should I be limiting all my arguments to 1024 bytes? or should this be
> an
> > > improvement in Glib?
> > 
> > I'm quite sure this limit is inherited from the syslog protocol
> > (which will be used to transfer the log messages in many cases).
> > The specification of the syslog protocol says that both the header
> > and the message together must be at most 1024 bytes (see RFC
> > 3164 section 4.1).
> 
> Does printf have the same limitations?  I am going to test this myself
> later tonight.

That sounds unlikely..

> > My recomendation is to keep log messages very brief (about one line > > of text) and maybe log additional information separately with
> > debug severity.
> 
> Debug severity? Do you mean like:
> 	g_log(domain, G_LOG_LEVEL_DEBUG, "%s", message);   
> 
> If so how would that differ from and other type of log level? If not
> how would I do it? fprintf/printf?
> 
> Most the logging is brief.  But if I receive a stream of data from a
> TCP socket which is 2048 bytes long, I then have a string which is too
> long to use with g_log().  I need to know what comes in from the
> socket, it is not acceptable to just ignore that information.
> 
> Can GLib not be improved to handle arguments similar to
> fprintf/printf/etc...?  I just wrote a simple application which filled
> a string with 4096 x characters and then did printf("%s", buffer) and
> it worked fine.  Surely Glibs implementation should be as good as
> printf at least.

Actually I don't have any experience of using g_log() and don't know what it is you want to log (but I implemented a log server some years ago so I know about logging). But then things are logged they are usually transered to a log server (on the same computer or another). This is done using the syslog protocol (RFC 3164), which can never handle more than 1024 bytes (acually slighty less). So in this (very common) case the messages will be truncated anyway.

The severity can be used by log analysers for sorting out messages that are not important enough. The most imortant messages might be used to trigger an alarm or send an e-mail to the administrator etc.

What is you are logging more exactly? If you don't need compatiblity with syslog (and then also the systems standard logging mechanism) you might want to use a custom logging system.