New LINT gag wanted
Richard O'Keefe
ok at edai.UUCP
Tue Mar 6 11:01:30 AEST 1984
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 <stdio.h> /* 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?
More information about the Comp.lang.c
mailing list