Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site watmath.UUCP
Path: utzoo!watmath!kpmartin
From: kpmartin@watmath.UUCP (Kevin Martin)
Newsgroups: net.lang.c
Subject: Re: ioctl's 3rd argument. Another possible solution :-)
Message-ID: <9895@watmath.UUCP>
Date: Sat, 17-Nov-84 16:16:03 EST
Article-I.D.: watmath.9895
Posted: Sat Nov 17 16:16:03 1984
Date-Received: Sun, 18-Nov-84 03:42:52 EST
Organization: U of Waterloo, Ontario
Lines: 26

Well, my mailer says:
554 steveg@hammer.UUCP... Don't know how to get to site hammer
so I guess I'll reply via news...

You forgot a fourth possible solution: For the cases where the 3rd arg should
be an int, change it to be a pointer to the int, so the 3rd arg is always an
pointer. Of course, the problem is upwards compatibility (or lack thereof).

I don't quite see the problem with the printf-style solution. After all, the
kernal eventually must decide if the arg was a pointer so that it can validate
it (or use it, if you can rely on the memory protection hardware).

The problem with allowing casting int into void* is that there is already
a significance to this (although non-portable, and varying from machine
to machine). On simple machines, casting 'n' into a pointer gives you
a pointer to location 'n'. Fine.
On other machines, casting 'n' into a pointer gives a pointer with bit pattern
'n' (in one machine, this gives byte # (n>>16) in segment (n&0xffff)).
The problem is that, on the latter form of machines, some integral values will
yield *illegal* pointers which cause faults when loaded into a pointer
register. Not loading a (void *) into a pointer register might be a solution,
but I can't guarantee that code for using (void *) will not become less
efficient if this is required. I would not want to sacrifice code
quality for the sake of a system call that my system doesn't even have.
                       Kevin Martin, UofW Software Development Group