From: "Marc Aurèle La France" <tsi@tuyoix.net>
To: Iain Buclaw <ibuclaw@gdcproject.org>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] gdc 9, 10 and 11 bug fix
Date: Tue, 17 May 2022 10:33:59 -0600 (Mountain Daylight Time) [thread overview]
Message-ID: <alpine.WNT.2.20.2205171029590.5632@CLUIJ> (raw)
In-Reply-To: <1652803794.4apc2k19jf.astroid@pulse.none>
On Tue, 17 May 2022, Iain Buclaw wrote:
> Excerpts from Marc Aurèle La France's message of Mai 17, 2022 5:31 pm:
>> On Tue, 17 May 2022, Iain Buclaw wrote:
>>> Excerpts from Marc Aurèle La France's message of Mai 16, 2022 11:34 pm:
>>>> On Sun, 15 May 2022, Iain Buclaw wrote:
>>>>> Excerpts from Marc Aurèle La France's message of Mai 12, 2022 10:29 pm:
>>>>>> No compiler has any business rejecting files for the sole crime of
>>>>>> being symlinked to. The following applies, modulo patch fuzz, to the
>>>>>> 9, 10 and 11 series of compilers.
>>>>>> Given my use of shadow trees, this bug attempted to prevent me from
>>>>>> building 12.1.0. The D-based gdc in 12.1.0 and up does not exhibit
>>>>>> this quirky behaviour.
>>>>> Thanks, I've checked upstream and see the following change:
>>>>> https://github.com/dlang/dmd/pull/11836/commits/ebda81e44fd0ca4b247a1860d9bef411c41c16cb
>>>>> It should be fine to just backport that.
>>>> Thanks for the pointer.
>>>> I ended up with the three slightly different diffs below, one each for
>>>> the 9, 10 and 11 branches. Each was rebuilt using 8.5.0, then used to
>>>> rebuild 12.1.0. All of this ran smoothly without complaint, although I
>>>> wouldn't want to do this on a 486...
>>>> Signed-off-by: Marc Aurèle La France <tsi@tuyoix.net>
>>>> For GCC 9 ---------- 8< ----------
>>>>
>>>> diff -aNpRruz -X /etc/diff.excludes gcc-9.4.0/gcc/d/dmd/root/filename.c devel-9.4.0/gcc/d/dmd/root/filename.c
>>>> --- gcc-9.4.0/gcc/d/dmd/root/filename.c 2021-06-01 01:53:04.716474774 -0600
>>>> +++ devel-9.4.0/gcc/d/dmd/root/filename.c 2022-05-15 15:02:49.995441507 -0600
>>>> @@ -475,53 +475,7 @@ const char *FileName::safeSearchPath(Strings *path, const char *name)
>>>>
>>>> return FileName::searchPath(path, name, false);
>>>> #elif POSIX
>>>> - /* Even with realpath(), we must check for // and disallow it
>>>> - */
>>>> - for (const char *p = name; *p; p++)
>>>> - {
>>>> - char c = *p;
>>>> - if (c == '/' && p[1] == '/')
>>>> - {
>>>> - return NULL;
>>>> - }
>>>> - }
>>> I'd keep this check in, otherwise removing/replacing only the `if
>>> (path)` branch looks OK to me.
>> The corresponding D code doesn't care about double slashes and neither
>> should this. Also, the comment is misleading as realpath() would no
>> longer be used here.
> True, but the D front-end does check the path in other places now:
> https://github.com/dlang/dmd/blob/e9ba29d71b557fe079e95ee6554f116b24159bab/src/dmd/root/filename.d#L787-L803
> https://github.com/dlang/dmd/blob/e9ba29d71b557fe079e95ee6554f116b24159bab/src/dmd/expressionsem.d#L5984-L6007
> If we remove all checks, then there'd be nothing to prevent either
> import("/file") or import("../file") from being used.
There is still no check for double slashes. All I want here is to fix a
C++ -> D migration bug without leaving any detritus behind.
Marc.
next prev parent reply other threads:[~2022-05-17 16:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-12 20:29 Marc Aurèle La France
2022-05-15 13:04 ` Iain Buclaw
2022-05-16 21:34 ` Marc Aurèle La France
2022-05-17 11:14 ` Iain Buclaw
2022-05-17 15:31 ` Marc Aurèle La France
2022-05-17 16:14 ` Iain Buclaw
2022-05-17 16:33 ` Marc Aurèle La France [this message]
2022-05-20 4:56 ` Marc Aurèle La France
2022-05-20 13:01 ` Iain Buclaw
2022-05-22 0:05 ` Marc Aurèle La France
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=alpine.WNT.2.20.2205171029590.5632@CLUIJ \
--to=tsi@tuyoix.net \
--cc=gcc-patches@gcc.gnu.org \
--cc=ibuclaw@gdcproject.org \
/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.
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 read-only IMAP folder(s) and NNTP newsgroup(s).