rename library routine in Microsoft C 3.0

Frank Whaley frank at sagan.UUCP
Sat Jan 18 05:08:11 AEST 1986


In article <6727 at boring.UUCP> guido at 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 at 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 at 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.



More information about the Comp.unix mailing list