guido@boring.UUCP (Guido van Rossum) (01/15/86)
Today I was bitten by a difference in interpretation of rename's arguments between my good old 4.2 BSD and the brand new (and otherwise GOOD!) Microsoft C compiler (3.0). BSD takes the first arg as the old file name and renames it to the second arg; Microsoft's library does it the other way around! Could anyone (besides Jim Cottrell :-) argue who is wrong? Lattice C (which used to be Microsoft C version 2.03) does it the BSD way, but I believe this function was added after the version that Microsoft sold was frozen. What does system 5 do (if it has one of these routines)? What does P1003 say about it? PS: I prefer the BSD way because it mimics mv(1). But I am willing to trade my opinion for an established standard. -- Guido van Rossum, CWI, Amsterdam (guido@mcvax.UUCP)
guy@sun.uucp (Guy Harris) (01/16/86)
> Today I was bitten by a difference in interpretation of rename's arguments > between my good old 4.2 BSD and the brand new (and otherwise GOOD!) > Microsoft C compiler (3.0). BSD takes the first arg as the old file name > and renames it to the second arg; Microsoft's library does it the other way > around! > Could anyone (besides Jim Cottrell :-) argue who is wrong? If Microsoft added it after 4.2BSD came out, they're totally wrong. Otherwise, it's somewhat a matter of opinion, except that 4.2BSD has a bit of de-facto standardness about it, so it's probably the preferable definition. > Lattice C (which used to be Microsoft C version 2.03) does it the BSD > way, but I believe this function was added after the version that > Microsoft sold was frozen. Another vote in favor of the BSD version. > What does system 5 do (if it has one of these routines)? It doesn't have a "rename" routine. > What does P1003 say about it? "The P1003 Working Group supports the X3J11 definition of the function 'rename()' with the additional provision that directories can be renamed." X3J11 does it the 4.2BSD way, which means Microsoft will have to change if they're going to be compatible with the C standard. (However, the P1003 draft says that it was agreed that "rename" will fail if the new file exists, which is not 4.2BSD compatible.) Guy Harris
frank@sagan.UUCP (Frank Whaley) (01/17/86)
In article <6727@boring.UUCP> guido@mcvax.UUCP (Guido van Rossum) writes: > Today I was bitten by a difference in interpretation of rename's arguments > between my good old 4.2 BSD and the brand new (and otherwise GOOD!) > Microsoft C compiler (3.0). BSD takes the first arg as the old file name > and renames it to the second arg; Microsoft's library does it the other way > around! > Could anyone (besides Jim Cottrell :-) argue who is wrong? > Lattice C (which used to be Microsoft C version 2.03) does it the BSD > way, but I believe this function was added after the version that > Microsoft sold was frozen. > What does system 5 do (if it has one of these routines)? > What does P1003 say about it? > PS: I prefer the BSD way because it mimics mv(1). But I am willing > to trade my opinion for an established standard. > Guido van Rossum, CWI, Amsterdam (guido@mcvax.UUCP) One of my favorite pasttimes is arguing that Microsoft is wrong. I was going to talk about all of the other libraries I have which use the (BSD?) "rename(old, new)" form, but instead I open the April 30 X3J11 draft to section D.9.4.2 and find: int rename(const char *old, const char *new); I would guess that Microsoft felt that this function falls into the same category as other "replacement" functions (strcpy(), memcpy()) where an algebraic notation (a = b) as opposed to algorithmic notation (b => a) is used. Some of us think in a noun/verb fashion ("a is replaced by b") while others prefer verb/noun ("move b into a"). Oops, I'm arguing... But I like standards, and code to fit them. -- ...Frank Whaley, MicroPro Product Development UUCP: {decvax!decwrl | ucbvax}!dual! {hplabs | glacier}!well! seismo!lll-crg! ihnp4!ptsfa!micropro!sagan!frank ARPA: micropro!sagan!frank@lll-crg.ARPA "I'm told there are better programs [than WordStar], but I'm also told there are better alphabets." --William F. Buckley Jr.