david@ukma.uky.csnet (David Herron, NPR Lover) (11/10/86)
In article <5299@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <5068@ukme.ukma.uky.csnet> david@ukme.UUCP (David Herron, NPR Lover) writes: >-In article <840@ur-valhalla.UUCP> dave@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@UKMA.BITNET, david@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?)