bugGNU Gengetopt - Bugs: bug #65130, Specification error when using...

 
 

bug #65130: Specification error when using flag options in groups

Submitter:  Dirk Baechle <dirkbaechle>
Submitted:  Fri 05 Jan 2024 10:39:35 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Originator Name:  Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 07 Mar 2024 04:17:12 PM UTC, comment #2: 

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. ;)

Dirk Baechle <dirkbaechle>
Tue 05 Mar 2024 02:35:55 PM UTC, comment #1: 

Sorry for the (large) delay, kept planning it for the "next week" and lot of time have passed.  Thank you for the detailed report, I will try to take a look, sadly cannot guarantee when that will happen.

Gray Wolf <gray_wolf>
Group administrator
Fri 05 Jan 2024 10:39:35 PM UTC, original submission:  

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

Dirk Baechle <dirkbaechle>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #55526:  groupoption_with_flags.patch added by dirkbaechle (6KiB - text/x-patch - Suggested fix against current "master", including simple test case)
file #55525:  cmd.ggo added by dirkbaechle (221B - application/octet-stream - Example file for demonstrating the error)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gray_wolf (Posted a comment)
  • -email is unavailable- added by dirkbaechle (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-01-05 dirkbaechle Attached File- Added groupoption_with_flags.patch, #55526
    2024-01-05 dirkbaechle Attached File- Added cmd.ggo, #55525

    Back to the top

    Powered by Savane 3.13-bb6a.
    Corresponding source code