lint won't verify printf formatting against variable types??

[A. Lester Buck]

In article <328 at tree.UUCP>, stever at tree.UUCP (Steve Rudek) writes:
> I was surprised to discover that neither cc nor lint comments when printf
> formatting doesn't match variable types--I thought lint complained about
> everything!  In other words, lint won't comment on the following:
> int x;
> long y;
> printf ("x=%ld y=%d", x, y);
> 
> I'm trying to get a game called "conquer" to work on a Microport SysV/AT
> machine where ints are 16 bits rather than the 32 bits the author expected.

The Nutshell handbook "Checking C Programs with Lint" discusses this
problem.  Until we all have versions of lint that handle /*PRINTFLIKEn*/,
you might try using the program printfck.  "Andries Brouwer wrote this as a
quick hack to check the Hack & Quest sources."  It rewrites each printf-like
call to have the arguments as return values from functions, and then
includes a lint library for each function type.  This program, and several
more lint helper programs, are available from uunet!~/nutshell/lint/*.

I was writing some drivers on an RT under AIX 2.2.1 recently and had been
running them through lint regularly (after cobbling together a lint library
for kernel routines).  Then I was reading the Nutshell handbook above and
picked up one of the extended checkers (the one called "check", if I
remember).  It reported that I had a nested comment in the source, but I
thought that was rather odd.  Then I noticed that the nested comment was
reported in the system header file!#%$  Sure enough, here is a piece of
/usr/include/sys/kio.h from AIX/RT 2.2.1:

[ declaring a struct query ]

	caddr_t ccb;
	long ioard;
	union {
		struct {                /* disk device mini disk and floppy */
			long blk_num;    /* block # of last operation */
			long num_blks;   /*
				       ^^^^^^^
			char blk_size;   /* block size */
			char dev_add[3]; /* 24 bit physical device address */
			} vd;
		struct {                /* floppy device */
			long blk_num;    /* block # of last operation */
			char byte_sec;  /* bytes per sectors */
			char sec_track; /* sectors/track */
			char track_cyl; /* tracks per cylinder */
			char num_cyl;   /* number of cylinders */
			char blk_size;  /* block size in bytes */
			char res;
			ushort steprate;
			} fd;
		struct {                /* rs232 device */
			char c1;

Such discoveries send a chill down my spine.  I can think of several
possibilities, all bad, but the most likely is that the released version of
the headers is separated at some point from the "one true source" for AIX.
What other subtle bugs might have crept in with such a source code control
system?  Does this happen in other versions of Unix?

-- 
A. Lester Buck		...!texbell!moray!siswat!buck