Am 17.03.2017 um 23:29 schrieb Jeff King:
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?
POSIX specifies the behavior in this case as unspecified. An
implementation could offer a different extension, and e.g. return a
pointer to a static buffer. So the answer would probably be "yes" if
this was a patch meant for public consumption. For now it's only
compatible with BSDs, Windows, MacOSX, Linux. :)
René