fprintf

[Stef Walter]

On 06/09/2011 12:09 PM, Nikos Mavrogiannopoulos wrote:
> On Thu, Jun 9, 2011 at 10:33 AM, Stef Walter <stefw at collabora.co.uk> wrote:
> 
>>> Anyway but the serious thing is that p11-kit uses the fprintf(stderr,)
>>> to report warnings and errors. In a library this is not always optimal
>>> because noone might see those errors. In mod_gnutls for example
>>> noone will see those errors (and in other servers the msg might even
>>> end-up in the socket since many of the just close stderr and it is
>>> re-used for connections).
>> True. I want to make it possible to see errors and warnings easily. But
>> you're right, that when used in a daemon this is problematic. I've added two
>> new functions which help with this:
>>
>> p11_kit_be_quiet()
>> p11_kit_message()
>> Docs: http://p11-glue.freedesktop.org/doc/p11-kit/p11-kit-Future.html
>> What do you think?
> 
> I'd suggest having a function that increases (and enables)
> verbosity instead. I'll explain myself on why.
> 
> If p11-kit is used by libgnutls and librandom, both
> used by an application random2, then if I call
> p11_kit_be_quiet(), I'll disable verbosity even if
> librandom specifically wanted that.

I was hoping that it would go the other way around. That verbosity was
the default, since it's useful for many applications.  If mod_gnutls
knows that it is being used in an environment where printing to stderr
is problematic, then it disables the verbosity.

In the above example, even though librandom wants verbosity, it may be
harmful to use stderr in certain contexts (such as a daemon that closes
stderr, as you mentioned).

> Moreover p11_kit_message() suggests it cannot be
> thread-safe. So if two parallel runs of a p11_kit functions
> are execute (maybe for a different module), what error
> would sbd get?

It is thread safe. It only returns the message for the last p11_kit
function called on the same thread.

This is documented here:
http://p11-glue.freedesktop.org/doc/p11-kit/p11-kit-Future.html

> I don't know what would have be the optimal solution,
> that's why I'd suggest for a library to be silent unless
> told to.

Yes, perhaps that is optimal. I'm a bit torn between
silent-warnings-by-default and output-warnings-by-default.

I've seen way too many writers of applications and libraries seem to
ignore rigorous error reporting, which makes it hard to debug or
troubleshoot a library like this.

In addition p11-kit is designed to be used by more than one consumer
(such as library or application) in the same process. We want any of
these consumers to be able to 'veto' the verbose printing of messages to
stderr. This is for the reason that you mentioned previously about daemons.

If it was a function call to enable warning output, then how would the
caller know if it was safe to enable? It seems callers know when it's
*not* safe, and so a function that models this seems appropriate.

> In gnutls we solved that with callbacks because at that
> time I thought that the messages by gnutls are only useful
> to the end-application using them (e.g. for auditing). This
> would assume that the end-application would know about
> gnutls being used. This is not always the case, and that's
> why I don't suggest it as a solution.

Yes that's true. In addition callbacks have problems with deadlocks. If
a callback calls back into p11-kit, then we can have strange behavior.

FWIW, p11-kit has been designed with reentrancy in mind, but only from
particular locations. These are carefully guarded in the code, and well
commented. If every single warning was a possible reentrancy point, that
would complicate the code considerably.

Cheers,

Stef