home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.os.msdos.programmer:9326 comp.lang.c:13609
- Path: sparky!uunet!ferkel.ucsb.edu!taco!gatech!swrinde!sdd.hp.com!uakari.primate.wisc.edu!eng.ufl.edu!manta!zzang
- From: zzang@stat.ufl.edu (Zhuo Zang)
- Newsgroups: comp.os.msdos.programmer,comp.lang.c
- Subject: Re: BC++2.0 lseek problem(ALSO:lseek() question)
- Message-ID: <1992Sep13.140705.9173@eng.ufl.edu>
- Date: 13 Sep 92 14:07:05 GMT
- References: <1992Sep13.011428.25100@eng.ufl.edu> <1992Sep13.043839.8659@waggen.twuug.com>
- Sender: news@eng.ufl.edu (Usenet Diskhog System)
- Distribution: usa
- Organization: University of Florida
- Lines: 26
- Originator: zzang@manta
-
- In article <1992Sep13.043839.8659@waggen.twuug.com> alpha@waggen.twuug.com (Joe Wright) writes:
- >Using open() and read() and lseek() will usually guarantee
- >non-portability. These are OS functions, not C functions.
- >More specifically, they are Unix functions and not MSDOS
- >functions. I strongly reccommend fopen(), fseek(), etc.
- >
- >That aside, the main reason that seek doesn't work the same
- >on Unix text files and DOS text files is that DOS uses two
- >characters, \r\n, to terminate a line while Unix uses only \n.
-
- but when we use open("foo.c", O_RDONLY|O_TEXT) in MSDOS,
- (the O_TEXT bit is default, I put here just for emphasizing)
- open() is supposed to skip the \r, so shouldn't have any problem.
- it turns out the open() in TEXT mode has problem in BC++2.0
-
- >So the DOS text file has a few more characters in it than
- >the Unix one.
- >
- >--
- >Joe Wright alpha@waggen.twuug.com alpha@wyvern.twuug.com
-
-
- --
- Zhuo Zang[~{j0WA~}]
- Department of Statistics
- University of Florida Email: zzang@stat.ufl.edu
-