Microport Unix -- Large Model Problems

[David Herron, NPR Lover]

In article <5299 at brl-smoke.ARPA> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In article <5068 at ukme.ukma.uky.csnet> david at ukme.UUCP (David Herron, NPR Lover) writes:
>-In article <840 at ur-valhalla.UUCP> dave at valhalla.UUCP (Dave Carlson) writes:
>->A potential problem I smacked into yesterday when porting BSD to SV/AT
>->is ioctl(2) expects as the third argument:
>->union   { int iarg;
>->        char *cparg;}
>-Argh!  And you're doing a port of an operating system???
>Oh, good grief!  Mr. Carlson is talking about ioctl(), which is a
>well-known function whose third argument has a type that depends on
>its second argument's value; usually it's an (int) or a (struct termio *).
>The problem is not his; rather it is due to the SV/AT implementor
>changing ioctl()'s third argument to be a union.  This is in violation
>of the SVID and of common sense, since (as Mr. Carlson reports) this
>breaks correctly-written code.

Oops... I mispoke it seems.

When I read the original article I say "union {...}" and thought,
oh, of course that's the PROPER way to implement ioctl()'s.  (Never
mind that it's not the way they're implemented... I make a habit
of not remembering sticky details like that, and sweep on to the
grand innacuracies...)

I apologize for that much..

I just had a thought (while sweeping on to another grand innacracy)
about the architecture on the 80286.. how does the system call know
which segment of memory to look at when getting the value.  Never
mind, even with my poor knowledge of that architecture I can think
of a couple of ways of doing it (such as uiomove() looking at the
"model" of the process and doing appropriate things).
-- 
David Herron,  cbosgd!ukma!david, david at UKMA.BITNET, david at ms.uky.csnet
(I'm also "postmaster", "news", "netnews", "uucp", "mmdf", and ...)
(And also the ACM chapter chairperson.)
(And even an all-around nice guy.  Aren't you lucky to get something from me?)