git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Plato Kiorpelidis <kioplato@gmail.com>
Cc: git@vger.kernel.org, phillip.wood123@gmail.com, avarab@gmail.com
Subject: Re: [PATCH v2 04/15] test-dir-iterator: consistently return EXIT_FAILURE or EXIT_SUCCESS
Date: Mon, 09 May 2022 14:03:57 -0700	[thread overview]
Message-ID: <xmqq35hictaa.fsf@gitster.g> (raw)
In-Reply-To: <20220509175159.2948802-5-kioplato@gmail.com> (Plato Kiorpelidis's message of "Mon, 9 May 2022 20:51:48 +0300")

Plato Kiorpelidis <kioplato@gmail.com> writes:

> Throughout test-dir-iterator.c we were returning/exiting with either
> integers or EXIT_FAILURE. Improve readability and reduce mental load
> by being consistent with what test-dir-iterator returns through the
> test-tool. Returning mixed constants and integers could indicate that
> it matters for some reason e.g. architecture of test-tool and cmd__*
> functions.
>
> EXIT_SUCCESS and EXIT_FAILURE are specified by the C standard.
> That makes the code more portable and standardized.

And less portable for the invoking process of "git".  The invoking
process used to be able to depend ou getting WEXITSTATUS() from our
exit status to obtain "1" when we exited with 1; if we start exiting
with EXIT_FAILURE, there is no guarantee what non-zero value is used.

So, I am not sure if this is a good direction to go in.

> Signed-off-by: Plato Kiorpelidis <kioplato@gmail.com>
> ---
>  t/helper/test-dir-iterator.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Especially given that this is a helper for testing, we may want to
return/exit with different non-zero value at different places to
make it easier for the test script to tell where in the program we
decided to exit a failure.  IOW, if we return not EXIT_FAILURE but 2
(or whatever value that is not used elsewhere) in the first hunk,
and let the second hunk continue to return 1, then the calling test
script can tell which one decided to fail.

As to EXIT_SUCCESS, I do not have a strong opinion against it, but
because EXIT_FAILURE is a bad idea, we probably should avoid it for
consistency.

Thanks.

> diff --git a/t/helper/test-dir-iterator.c b/t/helper/test-dir-iterator.c
> index 659b6bfa81..81e931673e 100644
> --- a/t/helper/test-dir-iterator.c
> +++ b/t/helper/test-dir-iterator.c
> @@ -39,7 +39,7 @@ int cmd__dir_iterator(int argc, const char **argv)
>  
>  	if (!diter) {
>  		printf("dir_iterator_begin failure: %s\n", error_name(errno));
> -		exit(EXIT_FAILURE);
> +		return EXIT_FAILURE;
>  	}
>  
>  	while ((iter_status = dir_iterator_advance(diter)) == ITER_OK) {
> @@ -58,8 +58,8 @@ int cmd__dir_iterator(int argc, const char **argv)
>  
>  	if (iter_status != ITER_DONE) {
>  		printf("dir_iterator_advance failure\n");
> -		return 1;
> +		return EXIT_FAILURE;
>  	}
>  
> -	return 0;
> +	return EXIT_SUCCESS;
>  }

  reply	other threads:[~2022-05-09 21:04 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-09 17:51 [PATCH v2 00/15][GSoC] iterate dirs before or after their contents Plato Kiorpelidis
2022-05-09 17:51 ` [PATCH v2 01/15] t0066: refactor dir-iterator tests Plato Kiorpelidis
2022-05-09 17:51 ` [PATCH v2 02/15] t0066: remove dependency between unrelated tests Plato Kiorpelidis
2022-05-09 17:51 ` [PATCH v2 03/15] t0066: shorter expected and actual output file names Plato Kiorpelidis
2022-05-09 17:51 ` [PATCH v2 04/15] test-dir-iterator: consistently return EXIT_FAILURE or EXIT_SUCCESS Plato Kiorpelidis
2022-05-09 21:03   ` Junio C Hamano [this message]
2022-05-18 14:13     ` Plato Kiorpelidis
2022-05-18 17:57       ` Junio C Hamano
2022-05-09 17:51 ` [PATCH v2 05/15] test-dir-iterator: print EACCES and ELOOP errno set by dir_iterator Plato Kiorpelidis
2022-05-09 17:51 ` [PATCH v2 06/15] test-dir-iterator: print errno name set by dir_iterator_advance Plato Kiorpelidis
2022-05-09 17:51 ` [PATCH v2 07/15] t0066: better test coverage for dir-iterator Plato Kiorpelidis
2022-05-09 17:51 ` [PATCH v2 08/15] t0066: reorder tests from simple to more complex Plato Kiorpelidis
2022-05-09 17:51 ` [PATCH v2 09/15] t0066: rename test directories Plato Kiorpelidis
2022-05-09 17:51 ` [PATCH v2 10/15] dir-iterator: refactor dir_iterator_advance() Plato Kiorpelidis
2022-05-09 21:16   ` Junio C Hamano
2022-05-18 15:39     ` Plato Kiorpelidis
2022-05-10 13:04   ` Phillip Wood
2022-05-09 17:51 ` [PATCH v2 11/15] dir-iterator: open root dir in dir_iterator_begin() Plato Kiorpelidis
2022-05-09 17:51 ` [PATCH v2 12/15] t0066: rename subtest descriptions Plato Kiorpelidis
2022-05-09 17:51 ` [PATCH v2 13/15] dir-iterator: option to iterate dirs in pre-order Plato Kiorpelidis
2022-05-10 13:07   ` Phillip Wood
2022-05-18 17:40     ` Plato Kiorpelidis
2022-05-18 17:47       ` rsbecker
2022-05-18 18:09         ` Junio C Hamano
2022-05-18 18:36           ` rsbecker
2022-05-09 17:51 ` [PATCH v2 14/15] dir-iterator: option to iterate dirs in post-order Plato Kiorpelidis
2022-05-09 17:51 ` [PATCH v2 15/15] entry.c: use dir-iterator to avoid explicit dir traversal Plato Kiorpelidis
2022-05-10 13:10   ` Phillip Wood
2022-05-10 13:13 ` [PATCH v2 00/15][GSoC] iterate dirs before or after their contents Phillip Wood
2022-05-10 16:31 ` Junio C Hamano
2022-05-20 17:43   ` 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=xmqq35hictaa.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=kioplato@gmail.com \
    --cc=phillip.wood123@gmail.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.
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).