[Nagiosplug-devel] printf calls in library functions

[Holger Weiss]

* Matthias Eble <matthias.eble at mailing.kaufland-informationssysteme.com> [2007-07-23 17:37]:
> >> If I got it right, the definition of UNKNOWN in the guidelines
> >> won't let us do so in every case(strictly speaking).
> >
> > Good point that the exit is not always UNKNOWN. I'm happy that the
> > exit code is appropriate for the failure.
>
> So I'd say that I'll change the libs from return/printf to die where
> appropriate in the next days.

IMO, doing so is fine within library functions where we can (more or
less safely) assume that no caller will ever want to handle any error
condition within that function in any different way than exiting
immediately.  In this case, the advantage of dying within the library
function is that the caller won't have to check for success, which is
nice.  I'd document that by not returning success/failure from such
functions at all (that is, by returning void if the function doesn't
return other stuff).  Obviously, in this case the dying function must
print the reason for the suicide to STDOUT itself.

However, if the caller might want to handle some error condition
himself, I'd never die within that function, as all callers will then
always have to check for success anyway.  Another reason not to die
might be that the desired exit status might depend on the context.  In
these cases, I'd only return failure and make the error message
available to the caller by using some global errno(3)-like variable or
some errstr() function which uses a static errno within the library, for
example.  (If we extended our libraries to provide the caller with a
struct holding the library state, this struct could hold the errno
variable, but this would of course require more work.)

Whether or not library functions should optionally provide verbose
output and how to implement that seems to be an unrelated issue to me.
(I'd simply use a global variable, initialized to "no verbose output"
optionally modifiable by the caller.)

> >> We could introduce a global variable containing the short upper case
> >> service name (eg DISK)to also print it in library functions.
> >> This might, but hopefully won't affect translation strings.
> > 
> > I agree about the short name. Some plugins change the short name  
> > (such as check_tcp), but I think it is reasonable to assume that the  
> > short name is set before calling various common functions. I'm not  
> > too worried about the short name as this is not part of the interface  
> > with Nagios.

I never really understood why it's printed at all.  That's another
story, but as my idea of simply removing it from the plugin output would
make things easier here, I'll take the chance to start another thread
regarding this question later this evening :-)

Holger

-- 
PGP fingerprint:  F1F0 9071 8084 A426 DD59  9839 59D3 F3A1 B8B5 D3DE