Xref: utzoo comp.unix.xenix:2630 comp.lang.c:11183 Path: utzoo!attcan!uunet!husc6!bloom-beacon!mit-eddie!uw-beaver!cornell!rochester!pt.cs.cmu.edu!cadre!pitt!amanue!oglvee!jr From: jr@oglvee.UUCP (Jim Rosenberg) Newsgroups: comp.unix.xenix,comp.lang.c Subject: Re: lint on Altos 2000 is BROKE BROKE BROKE! Summary: lint can't seem to digest stdio.h Message-ID: <261@oglvee.UUCP> Date: 5 Jul 88 15:44:11 GMT References: <256@oglvee.UUCP> <8173@brl-smoke.ARPA> <259@oglvee.UUCP> <601@nmtsun.nmt.edu> Reply-To: jr@.UUCP (Jim Rosenberg) Organization: Oglevee Computer Systems, Connellsville, Pa Lines: 66 In article <601@nmtsun.nmt.edu> dieter@nmtsun.nmt.edu (The Demented Teddy Bear) writes: >In article <259@oglvee.UUCP> jr@.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