From: Heiko Voigt <hvoigt@hvoigt.net>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org, Jens Lehmann <jens.lehmann@web.de>,
Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Subject: Re: [PATCH v2 3/4] config: make parsing stack struct independent from actual data source
Date: Tue, 12 Mar 2013 17:27:35 +0100 [thread overview]
Message-ID: <20130312162734.GB4704@sandbox-ub.fritz.box> (raw)
In-Reply-To: <20130312110355.GE11340@sigill.intra.peff.net>
On Tue, Mar 12, 2013 at 07:03:55AM -0400, Jeff King wrote:
> On Sun, Mar 10, 2013 at 05:59:40PM +0100, Heiko Voigt wrote:
>
> > diff --git a/config.c b/config.c
> > index f55c43d..fe1c0e5 100644
> > --- a/config.c
> > +++ b/config.c
> > @@ -10,20 +10,42 @@
> > #include "strbuf.h"
> > #include "quote.h"
> >
> > -typedef struct config_file {
> > - struct config_file *prev;
> > - FILE *f;
> > +struct config_source {
> > + struct config_source *prev;
> > + void *data;
>
> Would a union be more appropriate here? We do not ever have to pass it
> directly as a parameter, since we pass the "struct config_source" to the
> method functions.
>
> It's still possible to screw up using a union, but it's slightly harder
> than screwing up using a void pointer. And I do not think we need the
> run-time flexibility offered by the void pointer in this case.
No we do not need the void pointer flexibility. But that means every new
source would need to add to this union. Junio complained about that fact
when I first added the extra members directly to the struct. A union
does not waste that much space and we get some seperation using the
union members. Since this struct is local only I think that should be
ok.
> > +static int config_file_fgetc(struct config_source *conf)
> > +{
> > + FILE *f = conf->data;
> > + return fgetc(f);
> > +}
>
> This could become just:
>
> return fgetc(conf->u.f);
>
> and so forth (might it make sense to give "f" a more descriptive name,
> as we are adding other sources?).
Will change that.
Cheers Heiko
next prev parent reply other threads:[~2013-03-12 16:28 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-10 16:56 [PATCH v2 0/4] allow more sources for config values Heiko Voigt
2013-03-10 16:57 ` [PATCH v2 1/4] config: factor out config file stack management Heiko Voigt
2013-03-12 10:52 ` Jeff King
2013-03-12 15:44 ` Heiko Voigt
2013-03-12 19:04 ` Jeff King
2013-03-14 6:36 ` Heiko Voigt
2013-03-10 16:58 ` [PATCH v2 2/4] config: drop file pointer validity check in get_next_char() Heiko Voigt
2013-03-12 11:00 ` Jeff King
2013-03-12 16:00 ` Heiko Voigt
2013-03-12 16:16 ` Heiko Voigt
2013-03-12 19:26 ` Jeff King
2013-03-12 19:18 ` Jeff King
2013-03-10 16:59 ` [PATCH v2 3/4] config: make parsing stack struct independent from actual data source Heiko Voigt
2013-03-12 11:03 ` Jeff King
2013-03-12 16:27 ` Heiko Voigt [this message]
2013-03-12 19:27 ` Jeff King
2013-03-10 17:00 ` [PATCH v2 4/4] teach config parsing to read from strbuf Heiko Voigt
2013-03-12 11:18 ` Jeff King
2013-03-12 16:42 ` Heiko Voigt
2013-03-12 19:29 ` Jeff King
2013-03-14 6:39 ` Heiko Voigt
2013-03-14 7:10 ` Jeff King
2013-03-14 7:39 ` Jeff King
2013-03-18 14:18 ` Heiko Voigt
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=20130312162734.GB4704@sandbox-ub.fritz.box \
--to=hvoigt@hvoigt.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jens.lehmann@web.de \
--cc=peff@peff.net \
--cc=ramsay@ramsay1.demon.co.uk \
/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;
as well as URLs for NNTP newsgroup(s).