Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 (MC840302); site mcvax.UUCP
Path: utzoo!watmath!clyde!floyd!harpo!decvax!mcvax!guido
From: guido@mcvax.UUCP (Guido van Rossum)
Newsgroups: net.lang.c,net.unix-wizards
Subject: lint and ioctl parameter types (4.2 BSD)
Message-ID: <5773@mcvax.UUCP>
Date: Fri, 6-Apr-84 08:54:08 EST
Article-I.D.: mcvax.5773
Posted: Fri Apr  6 08:54:08 1984
Date-Received: Sat, 7-Apr-84 06:20:07 EST
Organization: "Stamp Out Basic" Committee, CWI, Amsterdam
Lines: 27

I keep getting errors about inconsistent parameter usage for the second and
third parameter of ioctl when I run lint.  It may give the discussion on
pointer sizes some new oil to burn, that's why I post to net.lang.c.

In reverse order of the ioctl arguments:

The type of the third argument to ioctl is indeed problematic (as the manual
already says).  It can be a pointer to various structs, to long int or to
char.  Lint insists that it is (char*).
QUESTION: on systems where this matters (i.e., where sizeof(char *) !=
sizeof(int *)), how does the system treat this? (I could imagine a kernel
expecting various pointer formats depending on the second parameter.)

The type of the second ioctl argument is a harmless int.  I use the standard
constants from /usr/include/sys/ioctl.h: TIOCGETP, FIONREAD, etc.  Lint
complaints about this!  Looking at the definitions of these symbols, all I
can see is that they are a complicated mask constructed by oring together:
0x20000000 or 0x4000000 or 0x80000000, the size of the parameter type
shifted left 16 bits, a character shifted left 8 bits and some small
integer.  How come lint doesn't recognize this as an int?  What does it
think it is, then?!?

Any suggestions? (NO GUESSES PLEASE!)

--
	Guido van Rossum, "Stamp Out Basic" Committee, CWI, Amsterdam
	guido @ mcvax