From: Jonas Fonseca <fonseca@diku.dk>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: "Kristian Høgsberg" <krh@redhat.com>,
gitster@pobox.com, git@vger.kernel.org
Subject: Re: [PATCH 1/4] Add a simple option parser for use by builtin-commit.c.
Date: Wed, 3 Oct 2007 22:11:29 +0200 [thread overview]
Message-ID: <20071003201129.GB25856@diku.dk> (raw)
In-Reply-To: <Pine.LNX.4.64.0710011909291.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote Mon, Oct 01, 2007:
> On Mon, 1 Oct 2007, Kristian H?gsberg wrote:
> > On Sun, 2007-09-30 at 15:11 +0200, Jonas Fonseca wrote:
> > > > +
> > > > +extern int parse_options(const char ***argv,
> > > > + struct option *options, int count,
> > > > + const char *usage_string);
> > >
> > > I think the interface could be improved a bit. For example, it doesn't
> > > need to count argument since the last entry in the options array is
> > > OPTION_LAST and thus the size can be detected that way.
> >
> > Hehe, yeah, that's how I did it first. I don't have a strong preference
> > for terminator elements vs. ARRAY_SIZE(), but Junio prefers the
> > ARRAY_SIZE() approach, I guess. At this point I'm just trying the get
> > the patches upstream...
>
> FWIW I like the ARRAY_SIZE() approach better, too, since it is less error
> prone.
OK, I must have missed that comment. Good point.
Thanks for the comments both of you. It's great to have something to
work from. However, I also fear it will also require that some extra
flags or information is added to the option information to make it more
generally usable. But I guess that is easier to discuss in the context
of a patch.
--
Jonas Fonseca
next prev parent reply other threads:[~2007-10-03 20:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-27 4:50 [PATCH 1/4] Add a simple option parser for use by builtin-commit.c Kristian Høgsberg
2007-09-27 4:50 ` [PATCH 2/4] This exports the update() function from builtin-add.c as Kristian Høgsberg
2007-09-27 4:50 ` [PATCH 3/4] Implement git commit as a builtin command Kristian Høgsberg
2007-09-27 4:50 ` [PATCH 4/4] Move launch_editor() and stripspace() to new file editor.c Kristian Høgsberg
2007-09-27 9:05 ` [PATCH 2/4] This exports the update() function from builtin-add.c as Junio C Hamano
2007-10-03 22:03 ` Kristian Høgsberg
2007-09-27 11:47 ` Johannes Schindelin
2007-09-27 19:50 ` Junio C Hamano
2007-09-30 13:11 ` [PATCH 1/4] Add a simple option parser for use by builtin-commit.c Jonas Fonseca
2007-10-01 10:14 ` Johannes Schindelin
2007-10-01 10:31 ` Jonas Fonseca
2007-10-01 11:39 ` Johannes Schindelin
2007-10-01 15:00 ` Jeff King
2007-10-01 16:26 ` Kristian Høgsberg
2007-10-01 18:13 ` Johannes Schindelin
2007-10-03 20:11 ` Jonas Fonseca [this message]
2007-10-03 21:53 ` Kristian Høgsberg
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=20071003201129.GB25856@diku.dk \
--to=fonseca@diku.dk \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=krh@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.