Path: utzoo!attcan!uunet!samsung!umich!terminator!dabo.ifs.umich.edu!rees From: rees@dabo.ifs.umich.edu (Jim Rees) Newsgroups: comp.sys.apollo Subject: Re: novice bsd/sys5 question Message-ID: <1990Apr11.165209.18227@terminator.cc.umich.edu> Date: 11 Apr 90 16:52:09 GMT References: <1990Apr11.094410.21629@axion.bt.co.uk> Sender: usenet@terminator.cc.umich.edu (usenet news) Reply-To: rees@citi.umich.edu (Jim Rees) Organization: University of Michigan IFS Project Lines: 29 In article <1990Apr11.094410.21629@axion.bt.co.uk>, crouch@axion.bt.co.uk (Chris Rouch) writes: > I've just started using an apollo, running 10.2. From what I can gather > you're either in sys5 mode or bsd mode. Is there anyway of being in > both, i.e. is it possible to mix and match the include files and system calls. Possible if you're a cowboy, but dangerous. Actually it's safer now than it was in the past. Before sr10, the stat() structs were different in the two universes. Berekeley stat structs have 64 bit times in them, but sysV are only 32 bit, for example. As of sr10, each stat struct is actually the union (in the set theory sense, not the C language sense) of the stat structs for each universe. That's why you see lots of st_spares and st_rfus now. This causes trouble for sysV programs that assume, for example, that the atime and mtime are both 32 bits and adjacent to each other in the stat struct. There are several of these in sysV -- maybe touch or tar, I don't remember for sure. If you happen to know which calls are safe to make from the other universe, you can go ahead and make those calls. There is no little switch that makes sysV calls fail if called from the bsd universe. But knowing which ones will work and which won't is tricky, and subject to change at each release as Bell and Berkeley change the semantics of their calls. Sometimes the calls will work but have nasty side-effects if mixed. I don't know what would happen, for example, if you mixed Berkeley select() and sigvec() with their sysV equivalents within a single program.