From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/15040 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] coresight: getcwd: modify the processing of parameters Date: Tue, 17 Dec 2019 22:52:29 -0500 Message-ID: <20191218035229.GL1666@brightrain.aerifal.cx> References: <20191218025132.111684-1-liujie1@huawei.com> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="55084"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Liu Jie To: musl@lists.openwall.com Original-X-From: musl-return-15056-gllmg-musl=m.gmane.org@lists.openwall.com Wed Dec 18 04:52:45 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1ihQOD-000EGZ-BQ for gllmg-musl@m.gmane.org; Wed, 18 Dec 2019 04:52:45 +0100 Original-Received: (qmail 14033 invoked by uid 550); 18 Dec 2019 03:52:43 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 14001 invoked from network); 18 Dec 2019 03:52:42 -0000 Content-Disposition: inline In-Reply-To: <20191218025132.111684-1-liujie1@huawei.com> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:15040 Archived-At: On Wed, Dec 18, 2019 at 10:51:32AM +0800, Liu Jie wrote: > According to POSIX 2008, the getcwd() function shall fail if: > [EINVAL] The size argument is 0. > [ERANGE] The size argument is greater than 0, but is smaller > than the length of the string +1. > The size should not be assigned, even if buf is NULL, otherwise > the error ERANGE cannot be correctly judged. > > Signed-off-by: Liu Jie > --- > src/unistd/getcwd.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/src/unistd/getcwd.c b/src/unistd/getcwd.c > index f407ffe0..ee2e97e9 100644 > --- a/src/unistd/getcwd.c > +++ b/src/unistd/getcwd.c > @@ -9,8 +9,8 @@ char *getcwd(char *buf, size_t size) > char tmp[buf ? 1 : PATH_MAX]; > if (!buf) { > buf = tmp; > - size = sizeof tmp; > - } else if (!size) { > + } > + if (!size) { > errno = EINVAL; > return 0; > } This breaks getcwd(0,123) and similar; I think you missed that the behavior of such is unspecified (and even if it weren't explicitly unspecified, it would be undefined since a null pointer wouldn't meet the requirement to point to an array. See (DESCRIPTION): "If buf is a null pointer, the behavior of getcwd() is unspecified." and (RATIONALE): "On some implementations, if buf is a null pointer, getcwd() may obtain size bytes of memory using malloc(). In this case, the pointer returned by getcwd() may be used as the argument in a subsequent call to free(). Invoking getcwd() with buf as a null pointer is not recommended in conforming applications." We do differ from glibc and some other implementations here in that size is not used; rather the buffer allocated is always sized to match what's needed for the string. This behavior is outside the scope of the standard and arguably better than what other implementations do (it does not spuriously fail due to short size nor waste memory on an oversized buffer), but I recall someone complaining once that it differed. Rich