[comp.sys.sgi] Suppressing lint messages on arena_s and exit

tim@bhpmrl.oz.au (Tim Monks) (07/26/90)

Has anyone got some ideas on how to suppress lint messages concerning arena_s 
and exit ? If I run lint as follows
	morgana > lint -bu -lc -lmalloc foo.c
one the following program :

		#include <stdio.h>
		#include <malloc.h>

		int *NR_ivector(nl,nh)
		int nl,nh;
		{
			int *v;

			v=(int *)malloc((unsigned) (nh-nl+1)*sizeof(int));
			if (!v) exit(1);
			return v-nl;
		}

I get the following messages :

		foo.c
		==============
		Warning: (13)  struct/union arena_s never defined
		warning: possible pointer alignment problem
		    (9)  	


		==============
		value type declared inconsistently
		    exit   	llib-lc.brl(50) :: foo.c(10)

I'm not too grouchy over the warning about the pointer, that's fair, but how do I
stop the messages about arena_s and exit ?

Thanks,
	Tim


--
Dr. Tim Monks                                

Image Processing & Data Analysis Group   |   (direct) (+61-3)566-7448
BHP Melbourne Research Laboratories      |   (switch) (+61-3)560-7066
245 Wellington Rd, Mulgrave, 3170,       |   (fax)    (+61-3)561-6709
AUSTRALIA                                |   (EMAIL)  tim@merlin.bhpmrl.oz.au

guy@auspex.auspex.com (Guy Harris) (07/28/90)

>		Warning: (13)  struct/union arena_s never defined
>		warning: possible pointer alignment problem
>		    (9)  	
>
>
>		==============
>		value type declared inconsistently
>		    exit   	llib-lc.brl(50) :: foo.c(10)
>
>...how do I stop the messages about arena_s and exit ?

For "exit", the correct answer is probably "see how it's declared in
'llib-lc.brl', and either 1) fix 'llib-lc.brl' if it's misdeclaring it,
and try again, or 2) declare it that way - which is the proper way - in
'foo.c'."

The SunOS 4.0.3 System V environment "llib-lc" - which is based on the
System V one, which is the one I'd expect IRIX to use - says it returns
"void", i.e. nothing.

As for "arena_s", check if IRIX's "lint" supports a "-z" option. 
Berkeley added that option to "lint" to silence those sorts of
complaints; perhaps SGI picked it up.  (If not, perhaps they should pick
it up.)