Re: fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |
- From
Jeff King <peff@peff.net>
- Date
- Mar 17, 2017, 22:29 UTC
- Message-ID
- <20170317222902.isndsmzy43btxh4i@sigill.intra.peff.net>
- In-Reply-To
- <250f6b35-03c3-1fa8-8b6b-dfdc42660d8c@web.de>
On Fri, Mar 17, 2017 at 10:07:18PM +0100, René Scharfe wrote:
Show 22 quoted lines
> > As an extension to the POSIX.1-2001 standard, Linux (libc4, libc5, > > glibc) getcwd() > > allocates the buffer dynamically using malloc(3) if buf is NULL. In > > this case, the > > allocated buffer has the length size unless size is zero, when buf > > is allocated as big > > as necessary. The caller should free(3) the returned buffer. > > > > This sounds specific to Linux (though I am reading Linux man pages, > > which claim this; Also it seems I might have misread it as it also states > > "The pathname is returned as the function result and via the > > argument buf, if present."). > > I'm only interested in FreeBSD for now, as that's the platform Zenobiusz > reported the issue on and I haven't been able to reproduce it, so this is > still a bit exploratory, but hopefully getting closer. This extension is > used in the first version of pwd(1) in FreeBSD's repo, comitted 1994-05-26, > so it was supported there basically forever. > > The oldest version I found that's using the extention is NetBSD's pwd(1), > which was committed 1993-03-21 and carries a SCCS timestamp of 1991-02-20. > Visual Studio .NET 2003 supports it as well.
My big question is what happens on other platforms when they see a NULL (but 0-sized) buffer. Any reasonable implementation would just return ERANGE and we'd fall back to the existing code. But we often have to deal with unreasonable ones.
So do we need a "my OS understands getcwd(NULL)" build knob?
-Peff