RPM Community Forums

Mailing List Message of <popt-devel>

Bug with equal in abutting short option

From: Wayne Davison <wayned@samba.org>
Date: Sat 08 Mar 2008 - 10:13:06 CET
Message-ID: <20080308091306.GB14747@herod.dreamhost.com>
Popt has a bug where a short option with an abutting arg is parsed
incorrectly if there is an equal sign in the arg.  This can be seen
using the "test1" executable:

% ./test1 -2foo-bar
arg1: 0 arg2: foo-bar
% ./test1 -2foo=bar
test1: bad argument -2foo=bar: invalid numeric value
% ./test1 -21=bar
test1: bad argument -21=bar: unknown option

In the failure cases, the code takes "bar" as the arg to the -2 option,
and then tries to continue parsing the characters that follow the -2
(thus the numeric error for the 'f' option in the first failure, and the
unknown option error for the '=' in the second).

The following patch for 1.14 resets the longArg variable if there was
not a single-dash long-named arg found for an option with a single dash:

--- popt.c.orig	2008-02-16 16:52:18 -0800
+++ popt.c	2008-03-08 00:39:17 -0800
@@ -901,6 +901,7 @@ int poptGetNextOpt(poptContext con)
 
 	    if (!opt) {
 		con->os->nextCharArg = origOptString + 1;
+		longArg = NULL;
 	    } else {
 		if (con->os == con->optionStack && F_ISSET(opt, STRIP))
 		{

This fixes the problem, and had no adverse affects on any of the various
ways of using -2 and --arg2 (and also -arg2 if POPT_ARGFLAG_ONEDASH is
enabled for that option).

..wayne..
Received on Sat Mar 8 11:14:40 2008
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.