Re: Provide a means to activate dynamically the debug traces

[Akim Demaille]

Hi all,


Le 19 janv. 09 à 10:38, Akim Demaille a écrit :

> Le 14 janv. 09 à 11:16, Akim Demaille a écrit :
>
> > Le 10 janv. 09 à 22:25, Ralf Wildenhues a écrit :
> >
> > > > So what do you recommend to store persistent information?  A  
> > > > function
> > > > that returns some static variable (sort of a singleton)?  Or an
> > > > additional argument everywhere (gee...).  Maybe I can do it using
> > > > advices to hand over the verbosity flags, but that does sound  
> > > > like a
> > > > nuisance for the API.
> > >
> > > A lt_dlget* and a lt_dlset* function, if the user needs to be able  
> > > to
> > > provide a type.  Don't provide the user with a direct pointer if you
> > > don't have to.
> > >
> > > Note that I didn't say global variables are bad, although they are
> > > obviously bad, too, for two reasons: slow access, and, well,  
> > > globality.
> > > Assume that you write a library that uses ltdl internally, and I use
> > > your library in a program that also links against a completely  
> > > different
> > > library that also uses ltdl.  You'll most likely not want  
> > > interference.
> > > Well, in your case I'm not so sure.  But if not, then adding a  
> > > module
> > > loading advisor to change verbosity would seem appropriate.
> >
> > I thought about this, and I think that the best option would be to  
> > have a callback function with  a signature more or less like:
> >
> > void log(void* user_data, level_type level, const char* format, ...);
>
> Here is my proposal.
>
> There are a few issues on which I'd be happy to have feedback:
>
> - I discovered slist only afterwards, and I did not convert
>  my code to use it.  I believe it would bring nothing useful,
>  because we really need no specific features here.  Using
>  slist would probably require more auxiliary structures and
>  routines.  But I can understand the advantages of reusing
>  slist.
>
> - This interface is not convenient for messages that are forged
>  in several pieces (first "%s", and then "%s\n").  syslog does
>  not support them, so maybe I should just always require the log
>  message to be a \n-ending line?  It is annoying for
>  lt_dlloader_dump.  Maybe in this case I should forge a dynamic
>  string first, and log it afterwards, instead of logging several
>  lines.

Now every call to the logging functions is given a complete line.  I  
still provide the \n, but maybe I should not.  No strong opinion here.

> - I have not decided what LEVELs should be.  We could use
>  syslog's values.  No strong opinion here.  Or a bitfield?
>
> - I have to address stdarg portability, doc, tests, NEWS etc.
>
> <0001-Provide-support-for-user-logging-functions.txt>

Here is an updated version.

0001-Provide-support-for-user-logging-functions.txt
Description: Text document