Message ID | 20230106083118.2141-1-anothername27-unity@yahoo.com |
---|---|
State | Accepted |
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp712312wrt; Fri, 6 Jan 2023 00:32:43 -0800 (PST) X-Google-Smtp-Source: AMrXdXsh+nHCC6L1SWyEXqjlfz2OOHHDDulKNgECTcN3AB1SV1pXHNOqC885Xx4N0T19C288QcKS X-Received: by 2002:a17:907:c242:b0:7c1:453f:1aae with SMTP id tj2-20020a170907c24200b007c1453f1aaemr58803599ejc.37.1672993963668; Fri, 06 Jan 2023 00:32:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672993963; cv=none; d=google.com; s=arc-20160816; b=Xch48WaQCEFyh85DOyknvIzOaW7DfkWY/J485HxD7tszBvGswbLYwD/K3AzHwDS5ye cPqSfJf3BNd0gViG97F84GPc0Be5JkyM6N84R73Sv5SgjQIhc4p4DoRu9xf8lstlfa5/ I4e/EJOb2gCYy7IDo0yFVGYzkpXAMOiDlGXEg3X58wJt41WWn7+oY7KkHZ9c1pShVtTq 5XBGFdXraQl9vbsoYz5ZqQJGx2h5dUlyoxf7/otqoFStZUfrkqcAlTxINQigSfQxEZiw jryTMl+HVlnQFnOXldXyehhaawFd6U0MCbUmMbMOEepMJX4QQAAZLf1NkIVHGjV7DrsC 1b1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:reply-to:from:list-subscribe:list-help:list-post :list-archive:list-unsubscribe:list-id:precedence :content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:dmarc-filter:delivered-to :dkim-signature:dkim-filter; bh=7opx/jX5fXVzDjRTXSKv9qYOP2Q6jP02XPpZ2agfOYk=; b=y48f83cR9K7a6lOal6ciFJjZpMRyvzh9DQjP7S/UnsKOix60T/+U+6FEF72fNqw5Ic FmSC4gtsPWg5+T7zLHYFq2vCYVG/qCirTXIPQY62Ix7B14iDGHcvT+0Rqje0Yc3F5xp+ bGQXXE5FiMqcUL7ejMCKfOa2ilHJkJBd20MYC2tfv8CgK/M+vmO7I6DBcYQyU2vBDZdk w+M7EmTyFD4CWrOWg/6DzEMtfAetLdLlwrt0jpTOlDEWXIOdfsb/YOElnGkJRc3VGiQk 4va37t2hINAvEqs6hhsKDUEM7Hs4LEYFm8w9NVdxQ8Y13gQYG1yQJFV5/GzHNZRf2t1X mOXA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b="Pi3r/j/V"; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id z12-20020a05640235cc00b0048f0fcee950si1117990edc.492.2023.01.06.00.32.43 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Jan 2023 00:32:43 -0800 (PST) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b="Pi3r/j/V"; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7AEDF3858D28 for <ouuuleilei@gmail.com>; Fri, 6 Jan 2023 08:32:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7AEDF3858D28 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1672993962; bh=7opx/jX5fXVzDjRTXSKv9qYOP2Q6jP02XPpZ2agfOYk=; h=To:Cc:Subject:Date:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=Pi3r/j/Vxxv1uq9EdHMr9T0eLQg7SZMIf3jPeqBOuxVGO0WunKgr14iSXCBYOhIqL X2gj/3otBT12HhpebPJlQsRiYLbwI9gaCROqH/B7hlcgnLvatCWZkLzZIkAlq+nMb+ RPMMrJ0gESXEyrI93Zy4tdFugR0CVRZnpwrQs27M= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from sonic316-22.consmr.mail.ne1.yahoo.com (sonic316-22.consmr.mail.ne1.yahoo.com [66.163.187.148]) by sourceware.org (Postfix) with ESMTPS id AF48A3858D28 for <gcc-patches@gcc.gnu.org>; Fri, 6 Jan 2023 08:31:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AF48A3858D28 X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1672993913; bh=37vflfUzwmFNaR3jFJFY2ptAvYSE981Qa84Fj4InIek=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=VDXSbhJ0NJlQYHrPllqX1OCIAfhmuTE1ZKJyCt6qqWFJ1tQIx4AYG4BW5kM5kr1PBe1u0E2VVoM9o8rpoCFJKp4DeJl3GVSr4cJilyFDtc1c9T7dcC9PgitPxGMQChCyBo97J17DMc7sqRFNkMhZzQmfbvToqOVMuGgZ/HPcz2re7I91s/I1DFMnTtMv6MlMJyXMHzrBVBYRxoNPGlqyeCZ/E3vpvybTCjijFTGFZGsQflj7yV/64hI0kpbNX92XjHhKazXY4OvVHGo1JDfWeLOrfzDa1G33mdKPXCDDyfWF/OTIK8QGipLNPalSqq9Lg+iFIC4XHNkNlbwPW9gxag== X-YMail-OSG: ysMV2hkVM1l.432AiUwL6DibLxg48peQDMNrWlbbsfFbGEIsJRTPkg4f0qyZqjg aPhmH9ALw3GIz_BvhMK8JEL11f62Dz8jv5I6ZIZT7OFqpRxyzlnCBhGjKcjSfNshklmuKuBxz1mU 0U560V9iy28FfXBeKM6srlm6iJokKEJxTgc73ujjBgTKQjdSuwGktMzomp8WWW2gDp_dXghpy8m7 .6KRsqiSAMf7nw2i_e7fgttySPCy.ck4FOkUnsAsJCTk4JktbOHVYZpyo53RKlZ0nEhV7MWkysMB qvC5smBTZgDllmQjIszL1RXZfnGbPq3xBnKYk4gSLo7k0IKIIU6Dop7KY8zqyh4eD92zuqAKoPMv et7XHNwTOz571wxlvhjcx5YwM_b1YpDcY_keSF9EffZDsqBI.6KoSmOW3PwLF6wf6iMyE0x9MgwM bdzWgw9pnvKPWeEpYxpPrT20Y4Is55pk2vO3qvdTK3HxJ1FSXKp8DkLiPuJn8w2SZl6exiy2ep7S mXsoEJrF0UV4Rkm.VpJHIZSjk2GEd4Rj1WcALmpl1pf8rjVzFb2e2P5522BDB8vHQ2bCoX5kvz8u eVGexhc_5JMQn8Q3MhX0uTxPDyR1FXQnfZq6Zshj3mL4SjC9wrIjj3Tpmg2LmXj7kcMD4XE4hqrS kJJY1OK5iHeVXTBgYPLrkJUa_z72Eaz_u2AH.kowsxRuSs7nhqZgKZQKCZkTYSEmi20qibCQWJ3f xdNbNA2l5u37Wan71x2Z9v.aSD0OMV_vRNQvXom0SuchHFyTv.6E7ZsejkPZNMh3R6amRb9jaicM U0JlJAksxTohJxoNM0wK03u1v4_pNwtkQ78M8sTSQpMTiTDhOZOxz3cx83twuzeY3xrAKGT9rr9G n9Yr0OdYt6xfETa0ZswW0dxZtVpOsD3wXGUMChKxYMy7rPkNNYDTpVPC5iVQ8Gf8mEyfbdE0b5RD GrrxM9njda07sEdnvum9uzvjkXuVzOXxQzQT8zYxOyvloHQeDlEeTqOUfCDxR1qcnkPa1nGy7kPJ eavu..jc.XEvBycE.lYzodb_OMdAAPq07wHCmjyqYG94POn9H3yEihvwZhQfeOrlz5mnnac3dlWN Ve2369pq2kUHGt4gusyehz1U8hntRByVE576xPPPl4NgcCo4AKIL69nsmmNsFJ0qhfpFwpOCatom i4QeQskED8bCLT6QnAS7_3GePi.yQcRygJA7EUMwFoe4BNQWJ7hPVQzfIDELSEWAo.m7y66AGlPL MFtGI5IZiOlOTScv1xHPlEMV41BE2W586zb8jniTghySmncyKwlNa1ebQ4hmyqrx8TLoiEJ74_Z4 32w.ummh0qlaNkQycBUHMwMDUQM1oItqcDt_vwFZnV.LzgHVcwMjX_nx98Rr3.ManpQX7lQb4gIY KN.iHjZ_G4cRIUnbVTQoa4i31neqQWTvioTTNhGhSggQZaOoLP_MffzWQY4ez.Z3LLfmzh.Yrz9v BXPVMfjDtX5g9RaTJKdnEKjc9B95ed1DNRkthyE8GBjU5fIf89MjQUM2HO1H9RJkFpzH.hk2AB9u wcwgXC02hy.NVp7zmPmJ_OezCm1DvurRMXvKq7iLirPQuRwg5c0.hOXYrpvOThnSWsQfi7X4jRkJ Ssgji_bUoIueN61xW9jt7DnKtZEaVQBsQqsJ9w7Z5WTuLV8rl81N.jvoaEoPxQdVRjc3yHxe2lwo aCzTNC5.jZ.tN8rPAfaM043zTkU3upKtiA9X9nHttgerCsMTxhENgMxJ1PB9gd2mn5oXWdIG_Rku jwiWLQD61e4vV5NKYOmrxFxTeWkIfHUxBr33QlqQhiRdqL4i5FDjSwr3vnSso2ojaqr3yF_mQzEA KB9B4Ougrh3hllCABavhj0ncjAR15Z_WOfERNmfMr6NhubTcL0H3Iy4hK83MKgAVsPqVGwjflVsw NKn4p4XAiCVZYUd1kcQnI0lJ3vYHRXhnqqudGS8ei2ehDZO5erUvaWvNXWCvsC6B3S5qFnTjMbe1 5SUDXkafgSAEnIXWHxDwE0MuHZ5ZauvxgP9K6Y6C2MTaWRjcGlOKN5Khv6twnHZOOlK9FXZrOSCj S.ZMZUtHD3TqRZQ2OwncOZOVH4qMdT990DfL9qMh1mESvymABKYJ7qh9y7avZjYyeLkj3DAu1_xZ kXbtQQq83zTFyNufIuhrj7eDBfN.yeOBHI_p4vMf2CK60o6Pd1qBBaIqyfBXW1GTZh5Xhiw_r0j1 cobC_QHc0iNo_giJrOBMsKrbklbxs.hq5_OpRQgvAgG0- X-Sonic-MF: <himalr@yahoo.com> Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.ne1.yahoo.com with HTTP; Fri, 6 Jan 2023 08:31:53 +0000 Received: by hermes--production-gq1-d898c4779-kpcpf (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f0f83334c17b94277bf1625af9158c36; Fri, 06 Jan 2023 08:31:47 +0000 (UTC) To: gcc-patches@gcc.gnu.org Cc: Himal <himalr@proton.me> Subject: [PATCH] Handle Windows nul device in unlink-if-ordinary.c Date: Fri, 6 Jan 2023 14:01:18 +0530 Message-Id: <20230106083118.2141-1-anothername27-unity@yahoo.com> X-Mailer: git-send-email 2.39.0 In-Reply-To: <fNaJU0FQkpY1sbMSTBhtyL9Fe3rKjTMaPdqQoq0VZhJBQxB1UtH_QU19Rai4usWKkETmSjqNT7cW5JaJxPnLy6iDTYpq4LHcEZsk2twCHAE=@proton.me> References: <fNaJU0FQkpY1sbMSTBhtyL9Fe3rKjTMaPdqQoq0VZhJBQxB1UtH_QU19Rai4usWKkETmSjqNT7cW5JaJxPnLy6iDTYpq4LHcEZsk2twCHAE=@proton.me> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: anothername27-unity--- via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: anothername27-unity@yahoo.com Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1754260799037711990?= X-GMAIL-MSGID: =?utf-8?q?1754261318507107405?= |
Series |
Handle Windows nul device in unlink-if-ordinary.c
|
|
Checks
Context | Check | Description |
---|---|---|
snail/gcc-patch-check | success | Github commit url |
Commit Message
Li, Pan2 via Gcc-patches
Jan. 6, 2023, 8:31 a.m. UTC
From: Himal <himalr@proton.me>
Hi,
This might be a better fix.
Regards.
PS. I had to use a different email.
---
libiberty/unlink-if-ordinary.c | 6 ++++++
1 file changed, 6 insertions(+)
Comments
On 1/6/23 01:31, anothername27-unity--- via Gcc-patches wrote: > From: Himal <himalr@proton.me> > > Hi, > > This might be a better fix. > > Regards. > > PS. I had to use a different email. > > --- > libiberty/unlink-if-ordinary.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/libiberty/unlink-if-ordinary.c b/libiberty/unlink-if-ordinary.c > index 84328b216..e765ac8b1 100644 > --- a/libiberty/unlink-if-ordinary.c > +++ b/libiberty/unlink-if-ordinary.c > @@ -62,6 +62,12 @@ was made to unlink the file because it is special. > int > unlink_if_ordinary (const char *name) > { > +/* MS-Windows 'stat' function (and in turn, S_ISREG) > + reports the null device as a regular file. */ > +#ifdef _WIN32 > + if (stricmp (name, "nul") == 0) > + return 1; > +#endif Umm, wouldn't this return true for a real file called nul in the current directory? ie, don't you need to distinguish between the nul device and a file named nul based on the full path? And not being a windows person, I'd really like to see some documentation which indicates that stat on the null device will indicate its a regular file. Alternately if one of the windows experts here can chime in, it'd be appreciated. jeff
On 3/12/2023 1:48 AM, Jeff Law wrote: > > > On 1/6/23 01:31, anothername27-unity--- via Gcc-patches wrote: >> From: Himal <himalr@proton.me> >> >> Hi, >> >> This might be a better fix. >> >> Regards. >> >> PS. I had to use a different email. >> >> --- >> libiberty/unlink-if-ordinary.c | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/libiberty/unlink-if-ordinary.c >> b/libiberty/unlink-if-ordinary.c >> index 84328b216..e765ac8b1 100644 >> --- a/libiberty/unlink-if-ordinary.c >> +++ b/libiberty/unlink-if-ordinary.c >> @@ -62,6 +62,12 @@ was made to unlink the file because it is special. >> int >> unlink_if_ordinary (const char *name) >> { >> +/* MS-Windows 'stat' function (and in turn, S_ISREG) >> + reports the null device as a regular file. */ >> +#ifdef _WIN32 >> + if (stricmp (name, "nul") == 0) >> + return 1; >> +#endif Hi Jeff, Thanks for the response. > Umm, wouldn't this return true for a real file called nul in the > current directory? ie, don't you need to distinguish between the nul > device and a file named nul based on the full path? I don't think that we can create a file called nul under Windows. > And not being a windows person, I'd really like to see some > documentation which indicates that stat on the null device will > indicate its a regular file. Alternately if one of the windows > experts here can chime in, it'd be appreciated. > jeff I found these patches that might indicate the same thing. https://src.fedoraproject.org/rpms/binutils/blob/0b119dd9d51a3763db7d6fea1b51a03494cb96d8/f/binutils-CVE-2021-20197.patch#_121-135 https://github.com/msys2/MINGW-packages/pull/10541/files I would like to see some input from a Windows developer as well. BTW, This doesn't affecting anything. I stumbled upon this while debugging another [bug](https://sourceware.org/bugzilla/show_bug.cgi?id=29947). I noticed it's calling unlink function for the nul device as well, but it wasn't throwing any errors or anything like that. Regards.
On 3/12/23 23:15, Himal wrote: > On 3/12/2023 1:48 AM, Jeff Law wrote: >> >> >> On 1/6/23 01:31, anothername27-unity--- via Gcc-patches wrote: >>> From: Himal <himalr@proton.me> >>> >>> Hi, >>> >>> This might be a better fix. >>> >>> Regards. >>> >>> PS. I had to use a different email. >>> >>> --- >>> libiberty/unlink-if-ordinary.c | 6 ++++++ >>> 1 file changed, 6 insertions(+) >>> >>> diff --git a/libiberty/unlink-if-ordinary.c >>> b/libiberty/unlink-if-ordinary.c >>> index 84328b216..e765ac8b1 100644 >>> --- a/libiberty/unlink-if-ordinary.c >>> +++ b/libiberty/unlink-if-ordinary.c >>> @@ -62,6 +62,12 @@ was made to unlink the file because it is special. >>> int >>> unlink_if_ordinary (const char *name) >>> { >>> +/* MS-Windows 'stat' function (and in turn, S_ISREG) >>> + reports the null device as a regular file. */ >>> +#ifdef _WIN32 >>> + if (stricmp (name, "nul") == 0) >>> + return 1; >>> +#endif > > Hi Jeff, Thanks for the response. > >> Umm, wouldn't this return true for a real file called nul in the >> current directory? ie, don't you need to distinguish between the nul >> device and a file named nul based on the full path? > > I don't think that we can create a file called nul under Windows. > >> And not being a windows person, I'd really like to see some >> documentation which indicates that stat on the null device will >> indicate its a regular file. Alternately if one of the windows >> experts here can chime in, it'd be appreciated. >> jeff > > I found these patches that might indicate the same thing. > > https://src.fedoraproject.org/rpms/binutils/blob/0b119dd9d51a3763db7d6fea1b51a03494cb96d8/f/binutils-CVE-2021-20197.patch#_121-135 > > https://github.com/msys2/MINGW-packages/pull/10541/files > > I would like to see some input from a Windows developer as well. > > BTW, This doesn't affecting anything. I stumbled upon this while > debugging another > [bug](https://sourceware.org/bugzilla/show_bug.cgi?id=29947). I noticed > it's calling unlink function for the nul device as well, but it wasn't > throwing any errors or anything like that. I'm inclined to go ahead and commit this. I think the only other question I have is the use of stricmp. That's not strictly ISO, strcasecmp would be preferred. But I don't know enough about the windows environment to know if they picked up strcasecmp over time. jeff
diff --git a/libiberty/unlink-if-ordinary.c b/libiberty/unlink-if-ordinary.c index 84328b216..e765ac8b1 100644 --- a/libiberty/unlink-if-ordinary.c +++ b/libiberty/unlink-if-ordinary.c @@ -62,6 +62,12 @@ was made to unlink the file because it is special. int unlink_if_ordinary (const char *name) { +/* MS-Windows 'stat' function (and in turn, S_ISREG) + reports the null device as a regular file. */ +#ifdef _WIN32 + if (stricmp (name, "nul") == 0) + return 1; +#endif struct stat st; if (lstat (name, &st) == 0