No worries, take your time.
I'm just happy that the project isn't dead, and there is still someone listening/reading on the other side. ;)

Hi there,

I stumbled over this problem while trying to run an old GGO specification file
through the latest gengetopt v2.23:

  $ gengetopt < cmd.ggo
  gengetopt:5: invalid specification for this kind of option

where I'd expect gengetopt to create some output files cmdline.* without any error.

You can find the cmd.ggo file in question attached, the basic problem is the
combined usage of flag options together with the "group" feature.

I was able to trace this back to a change in 2007 (!) from release
v2.19.1 to v2.20 (or 97d5d195fcd1 to 78b4d484ea41 in git commits).

In src/gengetopt.cc:gengetopt_check_option (ll. 678) the setting of

  n->required_set = true

was introduced and in l. 714 this is done when a "group" keyword is specified
for the current line (n->group_value != 0).

But after this assignment, the presence of a "flag" keyword gets checked (ll. 749).
If we try to use flags as a "groupoption" (n->type == ARG_FLAG), the n->required_set
(as just "overwritten") gets checked against "zero" (l. 755). This check always
fails and yields the error message as given above.

I have checked the commit messages in the git repo, the release notes and the mailing
archives, but couldn't find any hints that this break of behaviour was intentional.

If the original behaviour should be restored and no side effects are lurking, a
simple fix would be to move the "flags" check before the "group" check (and the possible
overwriting of the n->required_set variable).

In the appended patch I have implemented this against the current "master" commit
bef6597d1d07, and have also added a new test case...based on my cmd.ggo file. This should
help for keeping the behaviour consistent in future versions.

Best regards,

Dirk