Xref: news-dnh.mv.net comp.os.msdos.djgpp:218 Path: news-dnh.mv.net!mv!news.sprintlink.net!howland.reston.ans.net!swrinde!elroy.jpl.nasa.gov!news.larc.nasa.gov!lerc.nasa.gov!lerc.nasa.gov!babar From: gantose AT lerc DOT nasa DOT gov (Dave Gantose) Newsgroups: comp.os.msdos.djgpp Subject: Re: Code Standards Date: Wed, 07 Jun 95 18:03:35 GMT Organization: ADF, Inc. Lines: 46 References: Nntp-Posting-Host: babar.lerc.nasa.gov To: djgpp AT sun DOT soe DOT clarkson DOT edu Dj-Gateway: from newsgroup comp.os.msdos.djgpp Bob Babcock wrote: >> I'd want a warning that this rename() is very different than the one in the >> current djgpp or most other DOS C compilers. If you try to use it to move >> a file to another directory, and the move fails because there is a file of >> the same name in the target directory, that file is deleted and the move is >> attempted again. That's how I'd expect a unix rename to work, but a DOS >> rename would just fail. Then Eli Z. wrote: >That's right. V2.0's rename() is Unix-compatible by design (as far as DOS >lets us, that is). There is nothing in the ANSI standard to rule out such a >behavior, and it surely makes porting Unix programs a lot easier. The most >recent version that might be added to the final version of the library can >also move (prune and graft) a directory to another branch of the file >hierarchy. > >As long as this is properly documented, what's wrong with that? Now, my two cents worth: One thing to keep in mind, I think, is that not everyone using DJGPP is doing so because they know or like UNIX. I, for example, am not a UNIX afficionado, but I do use DJGPP. Apparently, there are cases where the UNIX assumption of the Right Thing To Do differs from the DOS assumption. In those cases, it is likely that the pure DOS user will get bitten by a "feature" he wouldn't have anticipated. To continue the above example, if I've often used rename() (or any other function), I'd feel no need to read the documentation for that particular function just because I got a new compiler or version. So the fact that it wasn't designed to work as I expected would probably appear to be an obscure problem. In reference to the phrase "properly documented", perhaps it would be good to have a document page that says "Here are functions whose regular performance differs between DOS and UNIX. You will want to be careful to read about them before using them in your code." And a mention of the DOS/UNIX difference would be a good thing in the documentation of the particular functions, too. Anyway, this kind of "heads-up" could help someone anticipate, and therefore avoid, potential problems. ============================================================================= Dave Gantose ADF, Inc. 2001 Aerospace Pkwy. phone: (216)977-1376 Brook Park, OH 44142 email: Gantose AT lerc DOT nasa DOT gov