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:	<D9sMLH DOT MCs AT jade DOT mv DOT net>
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

- Raw text -