jr@oglvee.UUCP (Jim Rosenberg) (06/24/88)
Here is a wee little piece of C:
t0.c:
#include <stdio.h>
struct shmoo {
int whoo;
char noo;
};
extern struct shmoo *scroo;
char *foo()
{
(void) fprintf(stderr, "I don't belive this!\n");
return (char *) scroo;
}
Below is what lint -u t0.c says about it on our system, which is an Altos
2000 running Xenix System V/386 v5.2c:
t0.c
==============
warning: illegal pointer combination
(13)
==============
function argument ( number ) used inconsistently
fprintf( arg 1 ) llibc(259) :: t0.c(12)
I don't believe this!!! Complaining because a struct * is cast to a char *??
On my AT&T 3B1 lint is perfectly happy with this, as it should be. But really:
lint doesn't know that stderr is a real live genuine (FILE *) ????
HELLLLLLLLLLLLP!!
Am I missing something?
Now that brings up another question. Altos seems to have this nasty habit of
not wanting to listen to you if you don't have a support contract. It makes
me furious to think I have to have a support contract to report bugs. The
Altos 2000 is a peach of a machine, but I've found *several* of the utilities
that were broken. Before it hasn't been any problem because I replaced them
with PD alternatives that are better anyway. But I can hardly replace lint!
Anybody out there have any clout with Altos?
--
Jim Rosenberg pitt
Oglevee Computer Systems >--!amanue!oglvee!jr
151 Oglevee Lane cgh
Connellsville, PA 15425 #include <disclaimer.h>gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/27/88)
In article <256@oglvee.UUCP> jr@oglvee.UUCP (Jim Rosenberg) writes: >I don't believe this!!! Complaining because a struct * is cast to a char *?? Assuming your C implementation supports void *, there SHOULD be a complaint. Try (char *)(void *)whatever if you really have to do this, or better yet don't use (char *) as a generic type.
jr@oglvee.UUCP (Jim Rosenberg) (06/29/88)
In article <8173@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >Assuming your C implementation supports void *, there SHOULD be a complaint. >Try (char *)(void *)whatever if you really have to do this, or better yet >don't use (char *) as a generic type. Well, thanks for the reminder that (void *) is supposed to replace (char *) as the generic pointer type, but that doesn't exonerate my lint, alas: return (char *) (void *) scroo; still produces a message "illegal pointer combination". In fact, it seems to me that the (void *) cast was the first thing I thought of, and it made no difference! With apologies to guardians of net bandwidth, here's the exact transcript of what she says using (void *) instead of (char *): t2.c: #include <stdio.h> struct shmoo { int whoo; char noo; }; extern struct shmoo *scroo; void *foo() { (void) fprintf(stderr, "I don't belive this!\n"); return (void *) scroo; } Output of lint -u t2.c: t2.c ============== warning: illegal pointer combination (13) ============== 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! -- Jim Rosenberg pitt Oglevee Computer Systems >--!amanue!oglvee!jr 151 Oglevee Lane cgh Connellsville, PA 15425 #include <disclaimer.h>
dieter@nmtsun.UUCP (06/30/88)
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). The one here (llib-lc) has: ... /* VARARGS2 */ int fprintf( f, s ) FILE *f; char *s; {return 1;} ... I have a funny feeling they have "int f" instead of "FILE *f". That's more of a bug in the description file than in lint itself. I am assuming that your vendor supplies the human-readable version of the lint libraries, which is probably a very silly thing to assume. However, maybe you got lucky. Dieter Muller -- Welcome to the island. You are number six. ...cmcl2!lanl!unm-la!unmvax!nmtsun!dieter dieter%nmt@relay.cs.net <-- most likely to succeed dieter@nmtsun.nmt.edu
jr@oglvee.UUCP (Jim Rosenberg) (07/05/88)
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 <disclaimer.h>
wes@obie.UUCP (Barnacle Wes) (07/10/88)
In article <261@oglvee.UUCP>, jr@oglvee.UUCP (Jim Rosenberg) writes: [Relates how lint is complaining about stdin on his system. The relevant portion of stdio.h is: > #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. Try type casting the definitions, like thus: #define stdin ((FILE *)&_iob[0]) #define stdout ((FILE *)&_iob[1]) #define stderr ((FILE *)&_iob[2]) This should cure your lint problem whithout screwing anything else up (I hope :-). BTW, my (Microport) System V stdio.h is just like your original, and lint likes it OK. Maybe you did get the lint from the Dead Sea Tapes. -- {hpda, uwmcsd1}!sp7040!obie!wes "Happiness lies in being priviledged to work hard for long hours in doing whatever you think is worth doing." -- Robert A. Heinlein --
lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) (07/12/88)
In article <94@obie.UUCP> wes@obie.UUCP (Barnacle Wes) writes: >In article <261@oglvee.UUCP>, jr@oglvee.UUCP (Jim Rosenberg) writes: ... > >#define stdin ((FILE *)&_iob[0]) >#define stdout ((FILE *)&_iob[1]) >#define stderr ((FILE *)&_iob[2]) > >This should cure your lint problem whithout [sic] screwing anything else up (I >hope :-). You'll have to rebuild any lint library '.ln' file that depends on any header file you've changed. Even adding a comment will blow lints little mind. If you need help rebuilding the '.ln' file let me know. -- Larry Cipriani, AT&T Network Systems and Ohio State University Domain: lvc@tut.cis.ohio-state.edu Path: ...!cbosgd!osu-cis!tut.cis.ohio-state.edu!lvc (strange but true)
chip@ateng.UUCP (Chip Salzenberg) (07/13/88)
According to jr@oglvee.UUCP (Jim Rosenberg): >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: >>> >>>I still don't capiche why lint is squawking about arg 1 to fprintf! >> >>Try looking at /usr/lib/lint/llibc... > >That was one of the first things I checked... I had this problem under SCO Xenix, until I re-generated the lint object files. What? You say you didn't know that lint can generate object files? Well, it can. Look for "/usr/lib/llib*.ln". These are pre-digested versions of the human-readable lint library files. They were, it seems, created back before some change was made to <stdio.h> and nobody at SCO bothered to regenerate them. To make new ones, at least under SCO Xenix, try something like this: $ su # cd /usr/lib # ln llibc llibc.c # lint -oc llibc.c # lint -LARGE -oc llibc.c # only for Xenix/286 # rm llibc.c # exit $ This should generate new versions of /usr/lib/llibc.ln, and for Xenix/286, /usr/lib/Lllibc.ln. Then try linting again. -- Chip Salzenberg <chip@ateng.uu.net> or <uunet!ateng!chip> A T Engineering My employer may or may not agree with me. You make me wanna break the laws of time and space You make me wanna eat pork
jr@oglvee.UUCP (Jim Rosenberg) (07/16/88)
From article <326@ateng.UUCP>, by chip@ateng.UUCP (Chip Salzenberg): > I had this problem under SCO Xenix, until I re-generated the lint object > files. What? You say you didn't know that lint can generate object files? > Well, it can. Look for "/usr/lib/llib*.ln". These are pre-digested > versions of the human-readable lint library files. They were, it seems, > created back before some change was made to <stdio.h> and nobody at SCO > bothered to regenerate them. > > To make new ones, at least under SCO Xenix, try something like this: > > $ su > # cd /usr/lib > # ln llibc llibc.c > # lint -oc llibc.c > # lint -LARGE -oc llibc.c # only for Xenix/286 > # rm llibc.c > # exit > $ Sigh. (64K times). My lint won't swallow -o. Does anyone know how to remake the .ln files on various versions of lint? Hint: tell me how to do it on the earliest version of lint you've ever heard of & I bet it will work. lint has a front end which is a shell script; here is my getopt line from that script: set -- `getopt abchl:npuvxI:D:U: $*` strings on /usr/lib/lint1 shows nothing that looks like a getopt string; when I used a doctored version of /usr/bin/lint and passed -o through to /usr/lib/lint1 it gagged and told me that was an illegal option. Then I get to figure out how to tweak /usr/lib/llibc so that lint no longer gives me **FRIGGING SYNTAX ERRORS** when run on its own lint library!!! I've played with this a little and the functions that are declared FILE * in the lint library cause copious syntax errors -- with completely bogus line numbers! This is getting extremely exasperating. I have better things to do with my time. Software engineering tools are the crown jewel of UNIX; one is supposed to USE them to improve programmer productivity, not waste time fixing them. Oh well, sorry for flaming, but I'm getting peeved. Hey, all I want is to find out where the warts are in *MY* code!!! -- Jim Rosenberg pitt Oglevee Computer Systems >--!amanue!oglvee!jr 151 Oglevee Lane cgh Connellsville, PA 15425 #include <disclaimer.h>
rsalz@bbn.com (Rich Salz) (07/26/88)
In comp.lang.c (<264@oglvee.UUCP>), jr@oglvee.UUCP (Jim Rosenberg) writes: >Sigh ... Does anyone know how to remake >the .ln files on various versions of lint? Here's the key. In most Unix-derived systems, lint has three passes -- cpp, lint1, lint2 -- usually controlled by a driver written in /bin/sh. To make a lint library, you have to basically feed your lint library through the first two passes, collect the output, and feed it to the last pass whenever you want it. In essence, then, you'll have to do something like this (split over multiple lines for readability): /lib/cpp -Dlint ${other -D -I -U options from the command line} YOURLINTFILE.c | $(LINTLIB)/lint1 ${lint flags from command line} >$(LINTLIB)/llib-lYOURLINTFILE.ln The LINTLIB variable will typically be /usr/lib or /usr/lib/lint. The direct call to /lib/cpp is probably not the best way to do it. Of the lint flags, most don't count or aren't needed; you probably want to use -v and -u, although if you have "/* LINTLIBRARY */" in your source than you don't need the -u. And, if you write your library so that every variable is used, you don't need the -v, as in: int chmod(f, m) char *f; int m; { f = f; m = m; return(0); } Now that you've made the library, how do you use it? Typically the "-lFILE" option tells the lint driver to feed the file $(LINTLIB)/llib-lFILE.ln into the second pass, where things like inter-module checking are done. So, if you name your file as shown in the fragment above, you should be okay. Hope this helps. /rich $alz -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.
jr@oglvee.UUCP (Jim Rosenberg) (07/28/88)
In article <1004@fig.bbn.com> rsalz@bbn.com (Rich Salz) writes: >In essence, then, you'll have to do something like this (split over >multiple lines for readability): > /lib/cpp -Dlint ${other -D -I -U options from the command line} > YOURLINTFILE.c > | $(LINTLIB)/lint1 ${lint flags from command line} > >$(LINTLIB)/llib-lYOURLINTFILE.ln >The LINTLIB variable will typically be /usr/lib or /usr/lib/lint. *** THANK YOU ***!!! For this particular C compiler I had to include the same options as in /usr/bin/lint. Here's a little script I used: : H=/usr/tmp/hlint$$ #header buffer file L=/usr/lib LL=/usr/lib #directories PATH=/bin:/usr/bin O="-E -C -Dlint" X= P=xenix #default parameters /bin/cc $O $1.c | $L/lint1 $X -H$H >$1.ln (Most of the above was just excised from /usr/bin/lint.) However, THERE WAS A CATCH! cc was blowing up completely on /usr/lib/llibc! It kind of spoils your whole day when you get syntax errors on the lint library, for crying out loud. To make matters worse, the line number in the syntax error was completely bogus. I finally managed to run the thing down, and it turned out to be a failure in llibc to give an #undef for clearerr. Evidently at some point in the past clearerr was a function; Microsoft or Altos or somebody changed it to a macro, and forgot to tweak the lint library accordingly. I've added the following line to /usr/lib/llibc: 195a196 > #undef clearerr /* oglvee!jr 7/28/88 */ Well, this is progress. Now to try to figure out how to get this creaking lint to shut up about perfectly reasonable casts. Many thanks again to all who helped. With apologies to the ghost of Louis Zukofsky: "Hear her clearerr ..." -- Jim Rosenberg pitt Oglevee Computer Systems >--!amanue!oglvee!jr 151 Oglevee Lane cgh Connellsville, PA 15425 #include <disclaimer.h>