RPM Community Forums

Mailing List Message of <popt-devel>

Re: Allow equal after a short option

From: Jeff Johnson <n3npq@mac.com>
Date: Sun 09 Mar 2008 - 15:51:42 CET
Message-Id: <CA53D05B-5A1F-4B0E-BEA1-65B8DC1F0A0F@mac.com>

On Mar 9, 2008, at 10:14 AM, Wayne Davison wrote:

> On Sun, Mar 09, 2008 at 12:42:37AM -0500, Jeff Johnson wrote:
>> /bin/echo on my system is unmodified from
>> Fedora 9 coreutils-6.10-4.fc9.i386
>
> Interesting.  So, what do you get with a manual run?
>
>     /bin/echo --foo --bar
>     /bin/echo -- --foo --bar
>

[jbj@wellfleet popt]$ /bin/echo --foo --bar
--bar
[jbj@wellfleet popt]$ /bin/echo -- --foo --bar
--foo --bar

Heh, I believe the answer starts to become clearer:
	The echo(1) from Fedora coreutils-6.10-4.fc9.i386 dares to be  
different.
The root cause is what I needed to understand. Thanks for the patience.

> I see all the option information output literally, including the --.
> What do you get if you try a "make check" using that perl -e patch
> instead of echo?  Does it still succeed for you?
>
>> I added the longArg = NULL, am seeing the same failure on test # 9.
>
> Very weird.  I don't see how my change could affect a short option's
> separated arg.  Attached is an even safer version of the change that
> ensures that the only time it ever sets longArg to NULL is if the
> longArg was set to oe + 1 upon finding an equal sign.
>
> I also tried using valgrind in the test suite:
>
>     result=`valgrind $builddir/$prog $*`
>
> and the test-run didn't turn up any errors.
>

Your
	longArg = NULL;
patch seems fine. The issue I'm seeing is here:
...
             origOptString++;
             if (*origOptString != '\0')
                 con->os->nextCharArg = origOptString;
#ifdef  NOTYET  /* XXX causes test 9 failure. */
                 con->os->nextCharArg = origOptString +  
(*origOptString == '=');
#endif
         }

         if (opt == NULL) return POPT_ERROR_BADOPT;      /* XXX can't  
happen */
...

If I turn that line on, popt "make check" (and rpm -q) breaks.

There's a class of problems, particularly with recursions like popt,  
that can fool valgrind.

Meanwhile, below is a rewrite of POPT_fprintf, essentially identical  
to the "man vsnprintf"
example. See what you think ...

(aside) I swear I wrote this code before, likely early June 2007,  
when the need for va_copy
on amd64/ppc was discovered. The issue was discussed at some length  
on <rpm-devel@rpm5.org>
during the 1st two weeks of June 2007.

int
POPT_fprintf (FILE * stream, const char * format, ...)
{
     char * b = NULL, * ob = NULL;
     size_t nb = 1;
     int rc;
     va_list ap;

     while ((b = realloc(b, nb)) != NULL) {
         va_start(ap, format);
         rc = vsnprintf(b, nb, format, ap);
         va_end(ap);
         if (rc < -1 && (size_t)rc < nb)
             break;
         if (rc > -1)    /* glibc 2.1 */
             nb = rc + 1;
         else            /* glibc 2.0 */
             nb += (nb <= 1 ? 100 : nb);
         ob = b;
     }

     rc = 0;
     if (b != NULL) {
#ifdef HAVE_ICONV
         ob = strdup_locale_from_utf8(b);
         if (ob != NULL) {
             rc = fprintf(stream, "%s", ob);
             free(ob);
         } else
#endif
             rc = fprintf(stream, "%s", b);
         free (b);
     } else if (ob != NULL)
         free(ob);

     return rc;
}

73 de Jeff
Received on Sun Mar 9 15:51:52 2008
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.