Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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.


  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