ioctl's 3rd argument. Another possible solution :-)

Kevin Martin kpmartin at watmath.UUCP
Sun Nov 18 07:16:03 AEST 1984

Well, my mailer says:
554 steveg at 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

More information about the Comp.lang.c mailing list