Message ID | 20220122144523.2221584-1-siddhesh@sourceware.org |
---|---|
State | Superseded |
Headers |
Return-Path: <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5D7863858419 for <patchwork@sourceware.org>; Sat, 22 Jan 2022 14:45:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5D7863858419 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1642862756; bh=r2iDrez8BGrJex8cl19KwvYBboWEJpeDP0SB1VWV8y4=; h=To:Subject:Date:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=jyzj6AzLrOeFQLo04G5S1rWMAXqghDZC5IJUNZ87SxqNmg3v3DFQsDnlgeNeGw4Wk pPBPdFTW++Pza/0Q6anYJz7cAaWycyhg55R3IgnL9cxZ/+SyeXNIr/LU6zHNjyUr0H SdNIYwIxrjz8OjruMayTlxHy5EjRUiNCIMjeGTKs= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from cyan.elm.relay.mailchannels.net (cyan.elm.relay.mailchannels.net [23.83.212.47]) by sourceware.org (Postfix) with ESMTPS id 0A8C53858D37 for <libc-alpha@sourceware.org>; Sat, 22 Jan 2022 14:45:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0A8C53858D37 X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id C1A93881917; Sat, 22 Jan 2022 14:45:34 +0000 (UTC) Received: from pdx1-sub0-mail-a306.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 70C6A8813C7; Sat, 22 Jan 2022 14:45:34 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from pdx1-sub0-mail-a306.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.121.92.88 (trex/6.4.3); Sat, 22 Jan 2022 14:45:34 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Supply-Shelf: 416dab654b1463fd_1642862734685_4165989060 X-MC-Loop-Signature: 1642862734685:109216018 X-MC-Ingress-Time: 1642862734685 Received: from rhbox.redhat.com (unknown [1.186.122.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a306.dreamhost.com (Postfix) with ESMTPSA id 4JgzZ44Blsz3n; Sat, 22 Jan 2022 06:45:32 -0800 (PST) To: libc-alpha@sourceware.org Subject: [PATCH] tst-realpath-toolong: Fix hurd build Date: Sat, 22 Jan 2022 20:15:23 +0530 Message-Id: <20220122144523.2221584-1-siddhesh@sourceware.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <alpine.DEB.2.22.394.2201212321551.199290@digraph.polyomino.org.uk> References: <alpine.DEB.2.22.394.2201212321551.199290@digraph.polyomino.org.uk> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3492.6 required=5.0 tests=BAYES_00, GIT_PATCH_0, JMQ_SPF_NEUTRAL, KAM_DMARC_NONE, KAM_DMARC_STATUS, RCVD_IN_ABUSEAT, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, RCVD_IN_SBL, SPF_HELO_NONE, SPF_NEUTRAL, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> From: Siddhesh Poyarekar via Libc-alpha <libc-alpha@sourceware.org> Reply-To: Siddhesh Poyarekar <siddhesh@sourceware.org> Cc: joseph@codesourcery.com Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> |
Series |
tst-realpath-toolong: Fix hurd build
|
|
Checks
Context | Check | Description |
---|---|---|
dj/TryBot-apply_patch | success | Patch applied to master at the time it was sent |
dj/TryBot-32bit | success | Build for i686 |
Commit Message
Siddhesh Poyarekar
Jan. 22, 2022, 2:45 p.m. UTC
We don't really need a bigger buffer for realpath since it should fail
and return NULL. In the bug too, the buffer itself is not accessed; it
is in fact left untouched. Drop the PATH_MAX use and pass a single char
address.
Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
---
stdlib/tst-realpath-toolong.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Comments
Siddhesh Poyarekar via Libc-alpha, le sam. 22 janv. 2022 20:15:23 +0530, a ecrit: > We don't really need a bigger buffer for realpath since it should fail > and return NULL. In the bug too, the buffer itself is not accessed; it > is in fact left untouched. Drop the PATH_MAX use and pass a single char > address. ? realpath assumes that the passed buffer is PATH_MAX-long. When PATH_MAX is not defined, calling it with a buffer is essentially undefined. Better just pass NULL. > Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> > --- > stdlib/tst-realpath-toolong.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/stdlib/tst-realpath-toolong.c b/stdlib/tst-realpath-toolong.c > index 8bed772460..ed84787a32 100644 > --- a/stdlib/tst-realpath-toolong.c > +++ b/stdlib/tst-realpath-toolong.c > @@ -34,8 +34,8 @@ do_test (void) > { > char *base = support_create_and_chdir_toolong_temp_directory (BASENAME); > > - char buf[PATH_MAX + 1]; > - const char *res = realpath (".", buf); > + char buf; > + const char *res = realpath (".", &buf); > > /* canonicalize.c states that if the real path is >= PATH_MAX, then > realpath returns NULL and sets ENAMETOOLONG. */ > -- > 2.34.1 >
On 23/01/2022 06:06, Samuel Thibault wrote: > Siddhesh Poyarekar via Libc-alpha, le sam. 22 janv. 2022 20:15:23 +0530, a ecrit: >> We don't really need a bigger buffer for realpath since it should fail >> and return NULL. In the bug too, the buffer itself is not accessed; it >> is in fact left untouched. Drop the PATH_MAX use and pass a single char >> address. > > ? realpath assumes that the passed buffer is PATH_MAX-long. When > PATH_MAX is not defined, calling it with a buffer is essentially > undefined. Better just pass NULL. Passing NULL doesn't reproduce the problem because realpath just allocates enough to accommodate the return, even when it exceeds PATH_MAX. It only applies when a non-NULL buffer is supplied. Would you prefer it if I defined PATH_MAX on hurd then, something like: #ifndef PATH_MAX # define PATH_MAX 1024 #endif or do you prefer a more accurate path_max value using pathconf()? The former will be a simpler fix, the latter will be best served by a get_path_max support function, which will be more elaborate but accurate. I'm happy to do either. Thanks, Siddhesh
Siddhesh Poyarekar, le dim. 23 janv. 2022 20:49:48 +0530, a ecrit: > On 23/01/2022 06:06, Samuel Thibault wrote: > > Siddhesh Poyarekar via Libc-alpha, le sam. 22 janv. 2022 20:15:23 +0530, a ecrit: > > > We don't really need a bigger buffer for realpath since it should fail > > > and return NULL. In the bug too, the buffer itself is not accessed; it > > > is in fact left untouched. Drop the PATH_MAX use and pass a single char > > > address. > > > > ? realpath assumes that the passed buffer is PATH_MAX-long. When > > PATH_MAX is not defined, calling it with a buffer is essentially > > undefined. Better just pass NULL. > > Passing NULL doesn't reproduce the problem because realpath just allocates > enough to accommodate the return, even when it exceeds PATH_MAX. Ah, ok, sorry I didn't check the whole story. > Would you prefer it if I defined PATH_MAX on hurd then, something like: > > #ifndef PATH_MAX > # define PATH_MAX 1024 > #endif > > or do you prefer a more accurate path_max value using pathconf()? Better use the accurate from pathconf() ; that being said it will return -1 on the ext2fs filesystem, so we'll have to resort to a hardcoded limit in that case anyway. I'm fine with just setting PATH_MAX by hand here. Samuel
diff --git a/stdlib/tst-realpath-toolong.c b/stdlib/tst-realpath-toolong.c index 8bed772460..ed84787a32 100644 --- a/stdlib/tst-realpath-toolong.c +++ b/stdlib/tst-realpath-toolong.c @@ -34,8 +34,8 @@ do_test (void) { char *base = support_create_and_chdir_toolong_temp_directory (BASENAME); - char buf[PATH_MAX + 1]; - const char *res = realpath (".", buf); + char buf; + const char *res = realpath (".", &buf); /* canonicalize.c states that if the real path is >= PATH_MAX, then realpath returns NULL and sets ENAMETOOLONG. */