"getcwd" vs. "getwd" (was Re: Re GNU emacs 18.55)

[Dave Olson]

In <3997 at auspex.auspex.com> guy at auspex.auspex.com (Guy Harris) writes:

| >It used to be (pre 3.3 days) that the current working directory was
| >obtained by the system call getcwd.  Now, to be POSIX conformant, the
| >system call is getwd, and getcwd is a subroutine which is implemented
| >by calling getwd.
| 
| Were it not for the fact that IRIX started out as an S5 derivative, I'd
| assume you'd reversed "getcwd" and "getwd" in the preceding paragraph,
| as the POSIX call to get the current working directory is "getcwd", not
| "getwd".  However, given that IRIX *did* start out as S5, I'd expect the
| call to get the current working directory to be "getcwd", as that's the
| S5 call; "getwd" is the BSD call.
| 
| If IRIX's "getcwd()" calls "getwd()", somebody got something backwards,
| as "getwd()" doesn't take a "maximum size of buffer" argument but
| "getcwd()" does.  Given that, a "getcwd()" that calls "getwd()" would
| have to throw said argument away, and would run the risk of having
| "getwd()" overrun the buffer if the string for the current working
| directory is too long....

The original poster is correct; in 3.3, getcwd does call getwd.  The
getwd call is not completely the same as BSD 4.3, it uses the POSIX
PATH_MAX (as does getcwd), instead of MAXPATHLEN; it won't return
anything longer.  getcwd calls getwd with a buffer of size PATH_MAX,
then checks the length to see if it is too long (for the error check),
and strncpy's it if not.

This is still faster than the 'standard' S5 getcwd, which does a popen
on /bin/pwd, and appears to have been done as part of some performance
tuning.  There were some minor changes for POSIX conformance also, but
they were independent of the change to use getwd.

Of course, neither getwd, nor getcwd are system calls, but are library
routines.
--

	Dave Olson

Life would be so much easier if we could just look at the source code.