Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!styx!ames!oliveb!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.lang.c
Subject: Re: pointer debate raging on...
Message-ID: <17897@sun.uucp>
Date: Sun, 3-May-87 14:11:04 EDT
Article-I.D.: sun.17897
Posted: Sun May  3 14:11:04 1987
Date-Received: Sun, 3-May-87 22:04:49 EDT
References: <149@sds.UUCP> <31@thirdi.UUCP> <17498@sun.uucp> <899@mhres.UUCP>
Sender: news@sun.uucp
Lines: 54
Keywords: pointers, religion, sin, Ritchie, razor blades, etc.

> I have had the bad experience that, on Xenix systems, lint performs its
> task assuming the small memory model (sizeof int == sizeof char). If your
> program is going to use large model (sizeof int != sizeof char), lint
> doesn't help ..... there is no way to tell lint to check with regard to
> another memory model.

Which just means that the Xenix "lint" is inadequate.  One would hope
that it would *still* complain about

	setbuf(stdout, NULL);

even if "sizeof(int)" == "sizeof(char *)" (which I presume is what
you meant above).

The System V lint has a particularly stupid feature - if
"sizeof(long)" == "sizeof(int)", it is silent about NULL not being
properly cast, unless you use the "-p" flag.

I might - barely - be willing to tolerate this *if* the "-p" flag
weren't significantly more stringent that is necessary, in most
cases, in the modern world.  Unfortunately, there are several
different flavors of portability, any of which might be of interest
in a particular case:

	1) Does it port to any reasonably "modern" UNIX C
	   implementation?  This check would require type-correctness
	   (i.e., "int", "short", and "long" should all be considered
	   different data types, and NULL should require a cast when
	   passed as an argument), and would check function calls against
	   a library that is either S5, 4.2BSD, or the intersection
	   thereof, but would permit very long names.

	2) Does it even port to less-modern UNIX C implementations?
	   This would also check that external names are unique in
	   the first 7 characters and non-external names are unique
	   in the first 8 characters.  It might check function calls
	   against a smaller library, too.

	3) Does it port to any ANSI C implementation (once said
	   standard emerges from the draft stage and is commonly
	   implemented)?  This would check that external names are
	   unique in the first 6 characters *after* case-folding, and
	   that non-external names are unique in the first 31
	   characters.  It would check function calls against a
	   library containing *only* the routines specified by the
	   ANSI standard.  (It would also disallow "#endif FOO",
	   since the ANSI C standard permits an implementation to
	   disallow this.)

	4) Does it port to any ANSI C implementation on a reasonably
	   modern OS?  This would loosen the restrictions on external
	   names to some degree.

It's not clear which of the above "-p" should specify.