From: Eli Zaretskii <eliz@gnu.org>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [patch 1/2] auto-load safe-path: Permit shell wildcards
Date: Wed, 20 Jun 2012 19:36:00 -0000 [thread overview]
Message-ID: <83txy5dbdd.fsf@gnu.org> (raw)
In-Reply-To: <20120620184032.GA13928@host2.jankratochvil.net>
> Date: Wed, 20 Jun 2012 20:40:32 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: gdb-patches@sourceware.org
>
> > > -filename_is_in_dir (const char *filename, const char *dir)
> > > +filename_is_in_pattern (const char *filename_orig, const char *pattern_orig)
> >
> > The arguments are named differently from what the commentary says.
> > (Do you really need the "_orig" suffix here?)
>
> I have split it now into filename_is_in_pattern and filename_is_in_pattern_1.
>
> As an explanation of the previous state:
>
> The problem is that I want to use bare "filename" in the code. Using
> "filename_local" (for example) may lead to mistakes as it is easier to
> accidentally write "filename" than to accidentally write "filename_orig".
>
> Using just "filename" everywhere would mean to make the parameter non-const
> ('char *filename') which may lead callers into thinking the string contents
> may be modified by this function. The code both uses and modifies the content
> of "filename".
So you wanted to use 'const', which dominoed into a whole bunch of
variable renaming and helper function. Looks like a net loss to me.
But I won't argue about style, since I'm usually in the minority on
that.
> > > + /* Trim trailing slashes ("/") from PATTERN. */
> > > + while (pattern_len && IS_DIR_SEPARATOR (pattern[pattern_len - 1]))
> > > + pattern_len--;
> > > + pattern[pattern_len] = '\0';
> >
> > Wouldn't this will do the wrong thing with a pattern such as "d:/"?
>
> It will trim it to "d:" and then it will try to remove /+[^/]+ each time from
> the filename reducing it also down to "d:". Therefore "d:/" will match any
> file on drive d:.
I'd say that warrants a comment, since the code looks plain wrong.
> > > @value{GDBN} provides the @samp{set auto-load safe-path} setting to list
> > > directories trusted for loading files not explicitly requested by user.
> > > +Each directory can be also shell wildcard pattern.
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > "... can also be a shell wildcard."
>
> I believe there should still be "shell wildcard pattern":
>
> set auto-load safe-path patternX:patternY
> set auto-load safe-path /directoryX1/directoryX2:/directoryY1/directoryY2
>
> I can say:
> set auto-load safe-path /usr/src*/.gdbinit
>
> So even a part of the directory ("src*") can be shell wildcard ("*").
> "src*" is IMO 'shell wildcard pattern' and not 'shell wildcard'.
> "*" is 'shell wildcard'.
I believe you are talking about "wildcard character" as opposed to a
"wildcard".
> Do you still insist on your wording?
I don't insist, but I still think "pattern" is redundant.
> > > + '*' matches only single
> > > +component, it does not match across directory separator.
> >
> > "... @samp{*} matches a single component ..."
> >
> > Should we describe all of the wildcard meta-characters, not just '*'?
>
> The goal was to express FNM_FILE_NAME is in use.
I understand, but I'm not sure the readers will. It sounds strange to
mention only one wildcard character, unless you already know that
FNM_FILE_NAME is the issue, and you also know what it does.
next prev parent reply other threads:[~2012-06-20 19:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-17 19:37 Jan Kratochvil
2012-06-18 16:09 ` Eli Zaretskii
2012-06-20 18:41 ` Jan Kratochvil
2012-06-20 19:36 ` Eli Zaretskii [this message]
2012-06-22 14:41 ` Jan Kratochvil
2012-07-02 10:58 ` [commit] " Jan Kratochvil
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=83txy5dbdd.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox