fprintf

[Stef Walter]

On 06/09/2011 01:30 PM, Nikos Mavrogiannopoulos wrote:
> On Thu, Jun 9, 2011 at 1:06 PM, Stef Walter <stefw at collabora.co.uk> wrote:
> 
>>> 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.
> 
> mod_gnutls or similar servers, might never know they use p11-kit
> on the background. Thus they shouldn't be expected to call a function
> of it.

That's true.

>>> 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.
> 
> Can this be guarranteed in a portable way? The format is the
> same as dlerror() which is an example of a non-reentrant
> function.

Yup it is reentrant and thread-safe. Using pthread functions to achieve
this, so it's as portable as pthread is. pthread is required by other
parts of p11-kit as well.

>> 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.
> 
> The problem then is who would veto? gnutls is a library, it cannot know whether
> it is used in a daemon, thus it would not. The end application daemon, might not
> know it is using p11-kit because it uses it via gnutls, thus it will
> not veto as well.

Good point. So then we have a real conundrum on our hands. Whether quiet
or verbose by default, no component using gnutls would really know
whether it was safe to enable the output.

Cheers,

Stef