Newsgroups: comp.sources.wanted Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!thunder.mcrcim.mcgill.edu!mouse From: mouse@thunder.mcrcim.mcgill.edu (der Mouse) Subject: Re: Low-level random-access I/O pkg sought Message-ID: <1991Mar23.103256.13352@thunder.mcrcim.mcgill.edu> Organization: McGill Research Centre for Intelligent Machines References: <31503@shamash.cdc.com> Date: Sat, 23 Mar 91 10:32:56 GMT Lines: 39 In article <31503@shamash.cdc.com>, ddh@hare.cdc.com (Dan Horsfall) writes: > I need an I/O package for a Un*x variant [...]. For basic > functionality, it needs only to be able to read and write arbitrary > byte-streams to or from arbitrary byte addresses/offsets in a file. > Reading an existing file is trivial with stdio: seek to address, move > bytes. Except for BA+LEN Writing poses some hurdles: My responses are based on the Berkeley stdio. I don't think anything I say is terribly Berkeley-specific, but y'never know. > 1) I'm told that stdio assumes EOF always follows the last byte > written; thus rewriting a block into the middle of an existing > file will likely trash the rest of it. Not so at all. You will need to take care when reading and writing the same file without closing and re-opening, but nothing more than a little care should be necessary; UNIX has always (at least since it escaped into the world) supported writing into the middle of an existing file. > 2) Writing to an offset beyond the previous EOF requires that > "something" be done in the intervening gap. It _is_ legal to > write to byte address 1,000,000 as the first operation on such a > file. UNIX normally deals with this just fine. stdio has no idea where EOF is, except when it stumbles across it while reading. In short, unless you have a spectacularly variant variant of UNIX, I would expect stdio to do just fine. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu