lint on Altos 2000 is BROKE BROKE BROKE!

[Jim Rosenberg]

In article <601 at nmtsun.nmt.edu> dieter at nmtsun.nmt.edu (The Demented Teddy Bear) writes:
>In article <259 at oglvee.UUCP> jr at .UUCP (Jim Rosenberg) writes:
>>
>> function argument ( number ) used inconsistently
>>    fprintf( arg 1 )   	llibc(259) :: t2.c(12)
>>
>>I still don't capiche why lint is squawking about arg 1 to fprintf!
>
>You have a good question.  Sun's lint only complains about "defined but
>not used" type things.  Try looking at /usr/lib/lint/llibc (or whatever
>the equivalent is on your machine).

That was one of the first things I checked, and the stuff in the lint library
sure looks OK to me:

	/*VARARGS2*/
int	fprintf(fp, fmt) FILE *fp; char *fmt; { return(0); }

The complaint about stderr not being a FILE * seems to be an inability by lint
to properly digest stdio.h.  FILE is defined as struct _iobuf, stderr is an
address in the list of _iob's; somehow lint doesn't quite get the fact that
these are supposed to be compatible!  Here's the relevant stuff from stdio.h:

#define	BUFSIZ	512
#define	_NFILE	50
#ifndef	FILE
extern	struct _iobuf {
	unsigned char	*_ptr;
	int	_cnt;
	unsigned char	*_base;
	char	_flag;
	char	_file;
} _iob[_NFILE];
#endif

...

#define	FILE	struct _iobuf

#define	stdin	(&_iob[0])
#define	stdout	(&_iob[1])
#define	stderr	(&_iob[2])

Boy this is pretty strange.  The #ifndef FILE is not the problem; when I get
rid of that lint still gives me the same complaint.  I tried replacing the
#define for FILE with a typedef struct _iobuf FILE; -- still the same result.
It does seem here that lint itself is genuinely a bit off its rocker.

I have a feeling this is some ancient version of lint from a fossil tape
somewhere.  One indication of this that whereas cc seems to have no problem
with flexnames, lint won't take them.  On my home 3b1 system both cc and lint
will understand flexnames.  uucico on this system also seems to be prehistoric
-- it apparently won't even understand escape sequences in L.sys entries.

The standard complaint people have about Xenix vs. "true" UNIX is that it's a
mishmash, e.g. you may get mostly System V stuff but still have a vanilla V7
boot sequence.  The Xenix System V on this Altos is much closer to true System
V than any other Xenix I've messed with -- the boot sequence is a real System
V inittab-driven boot sequence for instance.  I have a feeling the C compiler
has been well worked on but nobody bothered to even give a second glance to
lint.
-- 
Jim Rosenberg                        pitt
Oglevee Computer Systems                 >--!amanue!oglvee!jr
151 Oglevee Lane                      cgh
Connellsville, PA 15425                                #include <disclaimer.h>