git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Antoine Queru <Antoine.Queru@ensimag.grenoble-inp.fr>
Cc: git@vger.kernel.org, william.duclot@ensimag.grenoble-inp.fr,
	simon.rabourg@ensimag.grenoble-inp.fr,
	francois.beutin@ensimag.grenoble-inp.fr,
	Matthieu.Moy@grenoble-inp.fr,
	Antoine Queru <antoine.queru@grenoble-inp.fr>
Subject: Re: [PATCH] upload-pack.c: use of parse-options API
Date: Wed, 18 May 2016 14:08:00 -0400	[thread overview]
Message-ID: <20160518180800.GC5796@sigill.intra.peff.net> (raw)
In-Reply-To: <20160518164019.26443-1-Antoine.Queru@ensimag.grenoble-inp.fr>

On Wed, May 18, 2016 at 06:40:19PM +0200, Antoine Queru wrote:

> Option parsing now uses the parser API instead of a local parser.
> Code is now more compact.

Sounds like a good goal.

> -static const char upload_pack_usage[] = "git upload-pack [--strict] [--timeout=<n>] <dir>";
> +static const char * const upload_pack_usage[] = {
> +	N_("git upload-pack [--strict] [--timeout=<n>] <dir>"),
> +	NULL
> +};

Do we need to enumerate the options here now? The usage message should
list the options from "struct options", which make these redundant.

Something like:

  git -upload-pack [options] <dir>

probably makes more sense.

Of course, it's hard to read the usage message because...

> +	struct option options[] = {
> +		OPT_HIDDEN_BOOL(0, "stateless-rpc", &stateless_rpc, NULL),
> +		OPT_HIDDEN_BOOL(0, "advertise-refs", &advertise_refs, NULL),
> +		OPT_BOOL(0, "strict", &strict, NULL),
> +		OPT_INTEGER(0, "timeout", &timeout, NULL),
> +		OPT_END()
> +	};

You've left the description text for each of these options as NULL, so
running "git-upload-pack -h" segfaults.

I'm not sure whether it is worth hiding the first two options. We
typically hide "internal" options like this for user-facing programs, so
as not to clutter the "-h" output. But upload-pack isn't a user-facing
program. Anybody who is calling it directly with "-h" may be interested
in even its more esoteric options.

> -	for (i = 1; i < argc; i++) {
> -		char *arg = argv[i];
> -
> -		if (arg[0] != '-')
> -			break;
> -		if (!strcmp(arg, "--advertise-refs")) {
> -			advertise_refs = 1;
> -			continue;
> -		}
> -		if (!strcmp(arg, "--stateless-rpc")) {
> -			stateless_rpc = 1;
> -			continue;
> -		}
> -		if (!strcmp(arg, "--strict")) {
> -			strict = 1;
> -			continue;
> -		}
> -		if (starts_with(arg, "--timeout=")) {
> -			timeout = atoi(arg+10);
> -			daemon_mode = 1;
> -			continue;
> -		}
> -		if (!strcmp(arg, "--")) {
> -			i++;
> -			break;
> -		}
> -	}

A common pitfall in converting a for-loop to parse-options is when there
is anything stateful in the parsing loop. But I don't see anything here.
The trickiest thing is that --timeout implies daemon_mode. You've
handled that below as:

> +	if (timeout != 0)
> +		daemon_mode = 1;

I think that is OK. It would not be correct if, for example, some other
code set "timeout" to a non-zero value (e.g., a config option), but I
don't see that here.

As a style nit, we usually spell comparison-with-zero as just:

  if (timeout)
	daemon_mode = 1;

Looking at at daemon_mode, though, it appears that it cannot be set in
any other way except here. And it does nothing except to disable
progress in some cases. Weird. There may be some opportunities for
refactoring or simplification there, but I that is outside the scope of
your patch.

> +	argc = parse_options(argc, (const char **)argv, NULL, options, upload_pack_usage, 0);

Perhaps this is a good opportunity to use "const" in the declaration of
main(), as most other git programs do. Then you can drop this cast.

>  	setup_path();
>  
> -	dir = argv[i];
> +	dir = argv[0];
>  
>  	if (!enter_repo(dir, strict))
>  		die("'%s' does not appear to be a git repository", dir);

Prior to your patch, we used to check:

  -       if (i != argc-1)
  -               usage(upload_pack_usage);

which ensured that "dir" was non-NULL. But with your patch, we may pass
NULL to enter_repo. It fortunately catches this, but then we pass the
NULL to die, which can segfault (though on glibc systems, stdio is kind
enough to replace it with the "(null)").

Related, we silently accept extra arguments after your patch (whereas
before we showed the usage message). You probably want to check "argc ==
1", and otherwise show the usage message.

-Peff

  reply	other threads:[~2016-05-18 18:08 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-18 16:40 [PATCH] upload-pack.c: use of parse-options API Antoine Queru
2016-05-18 18:08 ` Jeff King [this message]
2016-05-19 10:10   ` Antoine Queru
2016-05-19 11:57     ` Jeff King
2016-05-19 14:36       ` Matthieu Moy
2016-05-19 15:39 ` [PATCH v2] " Antoine Queru
2016-05-19 16:10   ` Matthieu Moy
2016-05-19 16:46     ` Junio C Hamano
2016-05-20  6:55       ` Matthieu Moy
2016-05-19 16:58     ` Junio C Hamano
2016-05-20  6:53       ` Matthieu Moy
2016-05-20 16:52         ` Junio C Hamano
2016-05-23 13:02   ` [PATCH v3] " Antoine Queru
2016-05-23 18:03     ` Matthieu Moy
2016-05-27 14:16     ` [PATCH v4] " Antoine Queru
2016-05-27 14:52       ` Matthieu Moy
2016-05-27 16:59       ` Eric Sunshine
2016-05-30 14:27         ` Antoine Queru
2016-05-30 14:53       ` [PATCH v5] upload-pack.c: use " Antoine Queru
2016-05-30 15:06         ` Matthieu Moy
2016-05-30 19:26         ` Junio C Hamano
2016-05-31  9:53           ` Antoine Queru
2016-05-31 11:27           ` Matthieu Moy
2016-05-31 17:16             ` Junio C Hamano
2016-06-01 15:49               ` Antoine Queru
2016-05-31  9:57         ` [PATCH v6] " Antoine Queru

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=20160518180800.GC5796@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=Antoine.Queru@ensimag.grenoble-inp.fr \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=antoine.queru@grenoble-inp.fr \
    --cc=francois.beutin@ensimag.grenoble-inp.fr \
    --cc=git@vger.kernel.org \
    --cc=simon.rabourg@ensimag.grenoble-inp.fr \
    --cc=william.duclot@ensimag.grenoble-inp.fr \
    /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).