guy@auspex.auspex.com (Guy Harris) (09/02/90)
>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....
olson@anchor.esd.sgi.com (Dave Olson) (09/02/90)
In <3997@auspex.auspex.com> guy@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.
guy@auspex.auspex.com (Guy Harris) (09/03/90)
>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. I would have made "getwd()" a wrapper around "getcwd()" instead (pass PATH_MAX or MAXINT or whatever as the buffer size), and shoved the "getwd()" code into "getcwd()" in favor of the "popen()" code. A little less clumsy - no "strncpy()" needed - and a little less likely to surprise folks who have code that calls "getcwd()" and - for whatever reason - has its own routine named "getwd()". I'm not certain whether POSIX would actually *require* that "getcwd()" not drag in any routines with names that aren't part of the POSIX standard and don't begin with "_" (as the ANSI C standard does for routines it specifies, for quite good reason), but even if it isn't the law, it's still a good idea....