mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Cc: Liu Jie <liujie1@huawei.com>
Subject: Re: [PATCH] coresight: getcwd: modify the processing of parameters
Date: Tue, 17 Dec 2019 22:52:29 -0500	[thread overview]
Message-ID: <20191218035229.GL1666@brightrain.aerifal.cx> (raw)
In-Reply-To: <20191218025132.111684-1-liujie1@huawei.com>

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 <liujie1@huawei.com>
> ---
>  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


      reply	other threads:[~2019-12-18  3:52 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-18  2:51 Liu Jie
2019-12-18  3:52 ` Rich Felker [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191218035229.GL1666@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=liujie1@huawei.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).