Feature #4933
closed
getcwd(3c) could be more useful
0%
Description
Currently, correct use of getcwd(3c) requires one to loop until it a sufficiently large buffer is given to hold the return value or an error other than ERANGE is returned.
I would suggest that invoking getcwd(NULL, 0) should either return a malloc(3c)'d buffer containing the result, or NULL with errno set appropriately (I believe EACCESS and ENOMEM would be the two candidates). This would also match what other platforms (glibc, OS X, FreeBSD at least) do.
As all the standards I can find suggest that passing the first argument as NULL is undefined. As such, I believe that would allow us to ignore the 'EINVAL shall be returned when size is 0' clause (since presumably that only pertains to defined behavior).
Related issues
Updated by Gary Mills almost 9 years ago
Doesn't it already do this? The man page says:
If buf is a null pointer, getcwd() obtains size bytes of
space using malloc(3C). The pointer returned by getcwd() can
be used as the argument in a subsequent call to free().
Updated by Jason King almost 9 years ago
Not exactly -- all that does is malloc a buffer of 'size' and tries to use that. If 'size' wasn't large enough, it still fails and you have to call it again with increasingly larger values until it succeeds or returns some other error (which makes it of questionable utility IMO).
I don't see why we can't just do this looping for the caller when requested.
Updated by Andy Fiddaman over 2 years ago
- Related to Feature #13586: getcwd() should accept a 0 length argument added
Updated by Andy Fiddaman about 2 years ago
- Status changed from New to Duplicate
Closing this one now as #13586 has integrated.
(I should have added both issues to the change or closed the newer one but it's too late now)