Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 (MC840302); site erix.UUCP
Path: utzoo!watmath!clyde!akgua!mcnc!decvax!mcvax!enea!erix!per
From: per@erix.UUCP (Per Hedeland)
Newsgroups: net.lang.c,net.unix-wizards
Subject: Re: lint and ioctl parameter types (4.2 BSD)
Message-ID: <334@erix.UUCP>
Date: Fri, 13-Apr-84 15:48:05 EST
Article-I.D.: erix.334
Posted: Fri Apr 13 15:48:05 1984
Date-Received: Sun, 15-Apr-84 23:41:23 EST
References: <5773@mcvax.UUCP> <3334@brl-vgr.ARPA>
Organization: L M Ericsson, Stockholm, Sweden
Lines: 31

<>

>	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