git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Plato Kiorpelidis <kioplato@gmail.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: git@vger.kernel.org, matheus.bernardino@usp.br, mhagger@alum.mit.edu
Subject: Re: [RFC PATCH 3/6] dir-iterator: refactor dir_iterator_advance()
Date: Wed, 27 Apr 2022 18:45:26 +0300	[thread overview]
Message-ID: <20220427154526.uuhpkoee322l7kmz@compass> (raw)
In-Reply-To: <220411.86o817j2dt.gmgdl@evledraar.gmail.com>

On 22/04/11 01:11PM, Ævar Arnfjörð Bjarmason wrote:
> 
> On Sun, Apr 10 2022, Plato Kiorpelidis wrote:
> 
> > Simplify dir_iterator_advance by switch from iterative to recursive
> > implementation. In each recursive step one action is performed.
> >
> > This makes dir-iterator easier to work with, understand and introduce
> > new functionality.
> >
> > Signed-off-by: Plato Kiorpelidis <kioplato@gmail.com>
> > ---
> >
> > [...]
> >
> > @@ -45,34 +45,53 @@ struct dir_iterator_int {
> >  
> >  /*
> >   * Push a level in the iter stack and initialize it with information from
> > - * the directory pointed by iter->base->path. It is assumed that this
> > - * strbuf points to a valid directory path. Return 0 on success and -1
> > - * otherwise, setting errno accordingly and leaving the stack unchanged.
> > + * the directory pointed by iter->base->path. Don't open the directory.
> > + *
> > + * Return 1 on success.
> > + * Return 0 when `iter->base->path` isn't a directory.
> >   */
> >  static int push_level(struct dir_iterator_int *iter)
> >  {
> >  	struct dir_iterator_level *level;
> >  
> > +	if (!S_ISDIR(iter->base.st.st_mode)) return 0;
> 
> style: missing \n before "return".
> 
> Also, the one existing caller before this patch is:
> 
>     if (S_ISDIR(iter->base.st.st_mode) && push_level(iter))
> 
> Why not continue to do that?

In this patch I also fixed a problem that's subtle. Previously, when we called
dir_iterator_begin() and the specified path is invalid the call won't return
NULL. Instead the call succeeds and the first call to dir_iterator_advance()
fails. I believe that's unexpected. The expected behavior would be to return
NULL from dir_iterator_begin() if the specified path is invalid. Successful call
to dir_iterator_begin() suggests that the root path is valid.

To deal with that I introduced two states for the most recent directory. The
first is just pushed into the levels stack and the other pushed and activated.
This way we can "activate" the root directory in dir_iterator_begin(), but we
also need to reorder the calls to push_level() and activate_level() as a result.
We need to push directories after we read them and activate the most recent one
when dir_iterator_advance() is called.

I'll document that change in the related commit in v2.

Do you have any objection about this change?

> > +/*
> > + * Activate most recent pushed level.
> > + *
> > + * Return 1 on success.
> > + * Return -1 on failure when errno == ENOENT, leaving the stack unchanged.
> > + * Return -2 on failure when errno != ENOENT, leaving the stack unchanged.
> > + */
> > +static int activate_level(struct dir_iterator_int *iter)
> > +{
> > +	struct dir_iterator_level *level = &iter->levels[iter->levels_nr - 1];
> > +	int saved_errno;
> > +
> > +	if (level->dir)
> > +		return 1;
> > +
> > +	if ((level->dir = opendir(iter->base.path.buf)) != NULL)
> > +		return 1;
> > +
> > +	saved_errno = errno;
> > +	if (errno != ENOENT) {
> > +		warning_errno("error opening directory '%s'", iter->base.path.buf);
> >  		errno = saved_errno;
> > -		return -1;
> > +		return -2;
>
> Perhaps we should just add an enum for these return values instead of
> adding more negative/positive values here. That makes your later calls
> of activate_level() more idiomaic. E.g. !activate_level() instead of
> activate_level() == 1.

Yes, I agree. It was bothering me while I was writing these parts. I'm happy you
suggested a way to make this cleaner by using an enum.

> >  		warning_errno("failed to stat '%s'", iter->base.path.buf);
> > +		return -2;  // Stat failed not with ENOENT.
> 
> Don't use // comments, use /* .. */
> > +	} else if (stat_err && errno == ENOENT)
> > +		return -1;  // Stat failed with ENOENT.
> 
> Missing {} here for the else if.
> 
> > +	struct dir_iterator_int *iter = (struct dir_iterator_int *)dir_iterator;
> > +	struct dir_iterator_level *level = &iter->levels[iter->levels_nr - 1];
> > +
> > +	struct dirent *dir_entry = NULL;
> > +
> > +	int expose_err, activate_err;
> > +
> > +	/* For shorter code width-wise, more readable */
> > +	unsigned int PEDANTIC = iter->flags & DIR_ITERATOR_PEDANTIC;
> 
> We usually don't add \n\n in the middle of variable decls.
> 
> > [...]
> >
> > -		if (!de) {
> > -			if (errno) {
> > -				warning_errno("error reading directory '%s'",
> > -					      iter->base.path.buf);
> > -				if (iter->flags & DIR_ITERATOR_PEDANTIC)
> > -					goto error_out;
> > -			} else if (pop_level(iter) == 0) {
> > +	if (dir_entry == NULL) {
> 
> Don't compare against NULL, use !dir_entry.
> 
> [...]
> 
> > +		if (errno) {
> > +			warning_errno("errno reading dir '%s'", iter->base.path.buf);
> > +			if (iter->flags & DIR_ITERATOR_PEDANTIC) goto error_out;
> 
> more missing \n before goto/return.

I'll fix the coding style in these parts in v2. I'm sorry about that.

  parent reply	other threads:[~2022-04-27 15:49 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-10 11:18 [RFC PATCH 0/6][GSoC] iterate dirs before or after their contents Plato Kiorpelidis
2022-04-10 11:18 ` [RFC PATCH 1/6] t0066: improve readablity of dir-iterator tests Plato Kiorpelidis
2022-04-11 13:16   ` Phillip Wood
2022-04-24 19:25     ` Plato Kiorpelidis
2022-04-10 11:18 ` [RFC PATCH 2/6] t0066: better test coverage for dir-iterator Plato Kiorpelidis
2022-04-10 11:18 ` [RFC PATCH 3/6] dir-iterator: refactor dir_iterator_advance() Plato Kiorpelidis
2022-04-11 11:11   ` Ævar Arnfjörð Bjarmason
2022-04-11 13:40     ` Phillip Wood
2022-04-27 15:45     ` Plato Kiorpelidis [this message]
2022-04-11 13:26   ` Phillip Wood
2022-04-27 14:32     ` Plato Kiorpelidis
2022-04-10 11:18 ` [RFC PATCH 4/6] dir-iterator: iterate dirs before or after their contents Plato Kiorpelidis
2022-04-11 13:31   ` Phillip Wood
2022-04-27 14:57     ` Plato Kiorpelidis
2022-04-10 11:18 ` [RFC PATCH 5/6] t0066: remove redundant tests Plato Kiorpelidis
2022-04-11 11:10   ` Ævar Arnfjörð Bjarmason
2022-04-27 16:00     ` Plato Kiorpelidis
2022-04-10 11:18 ` [RFC PATCH 6/6] test-dir-iterator: handle EACCES errno by dir-iterator Plato Kiorpelidis
2022-04-11 11:04   ` Ævar Arnfjörð Bjarmason
2022-04-27 17:30     ` Plato Kiorpelidis
2022-04-11 13:37 ` [RFC PATCH 0/6][GSoC] iterate dirs before or after their contents Phillip Wood
2022-04-19 13:06   ` Plato Kiorpelidis

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220427154526.uuhpkoee322l7kmz@compass \
    --to=kioplato@gmail.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=matheus.bernardino@usp.br \
    --cc=mhagger@alum.mit.edu \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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).