Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83 (MC830713); site edai.UUCP Path: utzoo!watmath!clyde!floyd!vax135!ukc!edcaad!edee!edai!ok From: ok@edai.UUCP (Richard O'Keefe) Newsgroups: net.lang.c Subject: New LINT gag wanted Message-ID: <4054@edai.UUCP> Date: Mon, 5-Mar-84 20:01:30 EST Article-I.D.: edai.4054 Posted: Mon Mar 5 20:01:30 1984 Date-Received: Wed, 7-Mar-84 08:27:24 EST Organization: Art.Intelligence,Edin.Univ. Lines: 81 The general problem with Lint is that the programs it is most needed for are the ones it is least usable on. I've been trying to clean up a moderately large (7500-line) C program recently, and the following things have proven particularly annoying. 1. I am worried about portability of the program to 32-bit machines whose C compiler defines int=short. I am told that the ONYX C compiler for the Z8000 does this. I have carefully gone through the program writing "long" everywhere it matters, and putting "int" where it doesn't. But I didn't write the program. So I wanted Lint to find the places I'd missed. And you'd think that the -a flag would be exactly what you want. Indeed, the -a flag DID find **one** place I'd missed, which could have had disastrous consequences. BUT it also found over 50 other places, mostly of the form L =<< k; where L had been declared long. (There were other things with the same symptom but different etiologies.) WANTED: an option which reports on "int" := "long" and NOTHING ELSE. When I want to know about L =<< k, and I'm not silly enough to think that I shouldn't check these, I would rather have another option for that specific problem. 2. The program contains the following: #include/* defines NULL */ typedef long **ptr; ptr foo; baz(x) ptr x; {...} ... baz(NULL); ... foo = NULL; ... baz(foo); ... Lint is perfectly happy with foo = NULL; but complains about the "inconsistent usage" of baz's first argument. Given that K&R say that 0 is an acceptable pointer of any type, I don't find this at all helpful. This happens a lot in this particular program. What I'm worried about is functions with an "int" argument being passed "long" values, having to wade through some 34 bogus complaints of this nature really doesn't help. 3. The program has been ported from a VAX to a PERQ running ICL's PaNiX version of UNIX. PERQ pointers are normally to multiples of 16 bits, so char* and short* have a different representation. It's also been ported a machine whose normal addresses are long*. It *seems* to run on these machines, but as development takes place on the VAX it would be nice to check that future versions will port as well. So pointer alignment problems are very interesting. The trouble is that I know in advance that certain combinations will NOT cause problems on these machines. WANTED: a Lint declaration like /*ALIGNOK type1 type2*/ This declaration would mean that it is up to me to ensure that type1* can safely be converted to type2*. An instance of what I mean is typedef struct ugh { long a; struct ugh *b; } ugh, *ughp; /*ALIGNOK long ugh*/ The idea is that you would start out with none of these declarations, and Lint would find all the alignment problems it now reports. You'd check through them, and you'd find some that were ok, so you'd add an ALIGNOK declaration, and re-run Lint. You'd finally end up with just the set of alignment assumptions you needed, and if you wanted to try another machine, these declarations would tell you precisely which of the many possible combinations your program relied on. I have no access to the source of Lint. (We're running 4.1bsd.) Based on what I know about compiling in general, it doesn't seem all that tough to make these changes. Does anyone in netland know why it would be either impossible or undesirable to do so? Better still, has someone got a Lint we can copy that already has these or similar changes?