[Nagiosplug-devel] replacing common system calls with macros/inlines?

Ton Voon ton.voon at altinity.com
Wed Mar 22 03:12:08 CET 2006


On 21 Mar 2006, at 22:53, sean finney wrote:

> a thought for consideration:
>
> currently, there are a large number of places in plugin code
> where we have stuff like
>
> 	...
> 	foo=strdup(bar);
> 	if(foo==NULL) {
> 		printf("error message");
> 		exit(STATE_UNKNOWN);
> 	}
> 	...
>
> does it make any sense to introduce some macros to condense
> code a bit?  for example:
>
> 	static inline char* STRDUP(const char *foo){
> 		char *bar;
> 		bar=strdup(foo);
> 		if(bar==NULL){
> 			printf("error message");
> 			exit(STATE_UNKNOWN);
> 		}
> 	}
>
> and then everywhere in our plugin code we could replace the strdup() 
> +error
> detection calls with STRDUP(), and save ourselves some lines of  
> code in
> many places (and introduce missing/needed error checking in others).
>
> likewise, a similar approach could be taken for malloc, fopen, and
> probably others...
>
> thoughts?

I'm for this. My only concern is a consistent naming convention  
(though I'm guilty of this).

I notice you are proposing an uppercase version. I would prefer a  
prefix of np_.

I have a long term plan that "general" functions would move to an  
installed dynamic library which the core C plugins would use. Then  
also have something like apxs for Apache where a 3rd party could  
create a C program which could then compile and link to this library.

Generally, a plugin goes through this sequence:
   1) parse input parameters
   2) get a numeric value, X, related to what is being checked
   3) compare X against the specified thresholds

For check_mysql_query, I've started to get some general functions to  
parse thresholds (set_thresholds) and return status based on  
thresholds (get_status). These general functions are tested with  
libtap, so I think they are pretty reliable. These would be good  
candidates for inclusion into your check_apt.c.

If we agree on the naming convention, then I'll rename these functions.

Also, what's the best way of documenting? List in the dev guidelines  
the most useful functions?

Ton

http://www.altinity.com
T: +44 (0)870 787 9243
F: +44 (0)845 280 1725
Skype: tonvoon






More information about the Devel mailing list