guido@mcvax.UUCP (Guido van Rossum) (04/06/84)
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
gwyn@brl-vgr.ARPA (Doug Gwyn ) (04/08/84)
Look in /usr/lib/llib-lc to see what lint thinks ioctl looks like on your particular system. On my system the first two parameters are type int and VARARGS2 is specified. I never get complaints about ioctl from lint.
per@erix.UUCP (Per Hedeland) (04/13/84)
<> > On my system the first two parameters are type int and VARARGS2 > is specified. I never get complaints about ioctl from lint. VARARGS2 certainly shuts lint up about the third argument (it wasn't in our llib-lc, by the way), but that doesn't answer the original question on portability etc (I won't either), much less explains the problems with the second argument. Since I've been puzzled by those complaints too, I decided to have a closer look; it turned out that lint is perfectly happy when told (in llib-lc) that the second argument is a long! Grab Our Most Beloved Reference Manual, para 2.4.1 Integer constants: "... an octal or hex constant which exceeds the largest unsigned machine integer is likewise taken to be long". Hmmm... this is a vax, so that should mean "more than 32 bits used", which clearly isn't the case even with 0x80000000. If you haven't guessed it already, a bit of testing will show you that lint thinks that the size of an "unsigned machine integer" is 16 bits, no more! While lint certainly should complain about passing 32 bits as an int when given the -p option, the above behaviour seems very *wrong* to me. Or should llib-lc give the second argument as long on 4.2? Why your lint doesn't complain is a mystery to me (I wouldn't mind being enlightened). You *are* running 4.2, aren't you? Per Hedeland {decvax,philabs}!mcvax!enea!erix!per or per@erix.UUCP