git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Beat Bolli <dev+git@drbeat.li>
Cc: git@vger.kernel.org, gitster@pobox.com, Taylor Blau <me@taylorr.com>
Subject: Re: [PATCH] builtin/config: work around an unsized array forward declaration
Date: Thu, 5 Jul 2018 15:38:07 -0400	[thread overview]
Message-ID: <20180705193807.GA4826@sigill.intra.peff.net> (raw)
In-Reply-To: <20180705183445.30901-1-dev+git@drbeat.li>

On Thu, Jul 05, 2018 at 08:34:45PM +0200, Beat Bolli wrote:

> As reported here[0], Microsoft Visual Studio 2017.2 and "gcc -pedantic"
> don't understand the forward declaration of an unsized static array.
> They insist on an array size:
> 
>     d:\git\src\builtin\config.c(70,46): error C2133: 'builtin_config_options': unknown size
> 
> The thread [1] explains that this is due to the single-pass nature of
> old compilers.

Right, that makes sense.

> To work around this error, introduce the forward-declared function
> usage_builtin_config() instead that uses the array
> builtin_config_options only after it has been defined.
> 
> Also use this function in all other places where usage_with_options() is
> called with the same arguments.

Your patch is obviously correct, but I think here there might be an even
simpler solution: just bump option_parse_type() below the declaration,
since it's the only one that needs it. That hunk is bigger, but the
overall diff is simpler, and we don't need to carry that extra wrapper
function.

As a general rule for this case (because reordering isn't always an
option), I also wonder if we should prefer just introducing a pointer
alias:

  /* forward declaration is a pointer */
  static struct option *builtin_config_options;

  /* later, declare the actual storage and its alias */
  static struct option builtin_config_options_storage[] = {
	...
  };
  static struct option *builtin_config_options = builtin_config_options_storage;

There are occasionally cases where the caller really wants an array and
not a pointer, but in practice those are pretty rare.

I have a slight preference for the reordering solution in this case, but
any of them would be OK with me.

-Peff

  parent reply	other threads:[~2018-07-05 19:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-05 18:34 [PATCH] builtin/config: work around an unsized array forward declaration Beat Bolli
2018-07-05 19:35 ` Taylor Blau
2018-07-05 19:38 ` Jeff King [this message]
2018-07-05 19:50   ` Beat Bolli
2018-07-05 20:02     ` Jeff King
2018-07-06 19:24       ` Junio C Hamano
2018-07-07 23:58         ` Kim Gybels

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=20180705193807.GA4826@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=dev+git@drbeat.li \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=me@taylorr.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 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).