On Fri, Mar 17, 2017 at 10:07:18PM +0100, René Scharfe wrote: > > 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