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.
guido@boring.UUCP (Guido van Rossum) (01/18/86)
In a previous article with the above subject I noted a strange error in Microsoft C's library. I received several letters, none very informative, most to the tone of "Microsoft blew it again". That's not fair! While they may have slipped here, my general feeling towards their 3.0 C compiler and library is extermely positive. We received it just a week ago, and I have already decided to junk our (2.15) Lattice compiler completely. I have used it to compile some 20,000 lines of C, and with one exception it compiled flawlessly. The exception was a compiler assertion error, apparently caused by a too complicated expression (it was really HUGE). I can live with that. About two third of this code had earlier been used with Lattice, and MSC proved to be *extremely* compatible. They support almost all MS-DOS- specific functions and #include files in the Lattice library. The only thing that bit me (besides the rename bug) was the fact that Microsoft has signed characters -- my fault for not writing portable code. The other third had hardly ever left UNIX, and was full of things like exec, chdir, stat, chmod and signal. It was very easy to port, because Microsoft implemented almost all well-known UNIX system calls that can possibly be emulated on MS-DOS to some extent. My main problems with porting it were changing assumptions about file names (I was parsing paths and only took '/' as a delimiter) and finding a replacement for fork/exec/wait sequences -- not too difficult, since Microsoft provides functions spawn* that combine these three calls. But the best surprise was the execution speed of my program (even though I directed all optimizations to saving space): sometimes twice as fast! I could go on, but these are my actual experiences until now. The manuals are also of very good quality, and I am looking forward to using the overlay feature of the new linker. Next, I might try porting Gosmacs! P.S.: please don't send any more mail concerning rename. -- Guido van Rossum, CWI, Amsterdam (guido@mcvax.UUCP)