Bug 2016

Do you have a simple testcase handy?

Subject: Re:  argp --help infloop, via ARGP_HELP_FMT envvar

"decimal at us dot ibm dot com" <sourceware-bugzilla@sourceware.org> wrote:
> Do you have a simple testcase handy?

No.
FYI, there's already a fix in gnulib:

  http://lists.gnu.org/archive/html/bug-gnulib/2005-12/msg00042.html

Subject: Re:  argp --help infloop, via ARGP_HELP_FMT envvar

"decimal at us dot ibm dot com" <sourceware-bugzilla@sourceware.org> wrote:
> Do you have a simple testcase handy?

If you need a simple testcase, one of the four in
the glibc manual should do nicely.

I was able to reproduce.

Created attachment 799 [details]
A Minimal Program Using Argp

To reproduce the problem use
gcc -o glibc-2016-test glibc-2016-test.c
ARGP_HELP_FMT=rmargin=2 ./glibc-2016-test --help

Created attachment 801 [details]
Patch from gnulib to resolve this issue.

This patch was taken from
http://lists.gnu.org/archive/html/bug-gnulib/2005-12/msg00042.html
and resolves the problem. I have tested on ppc64 and ppc.

Sent a note to the gnulib argp maintainer to verify that copyright assignment
has already happened for this fix.

It seems the copyright assignment is in progress with the FSF.

The gnulib argp maintainer is interested in seeing other fixes get into glibc.
Not sure if there is any interest on the glibc end. Perhaps there is a policy to
only take fixes reported by users? or perhaps the goal would be to track gnulib
more closely if the resources were available to do it?

The policy wrt gnulib copies of glibc code is that glibc's trunk is the master
source and gnulib maintainers have previously agreed to submit fixes to glibc
piecemeal as they come up, so as to keep the code in synch.  gnulib maintainers
can contact me to expedite any languishing gnulib patches, and they should
already be aware of this.  Anyone doing glibc bugzilla triage can identify
patches from gnulib maintainers and assign those bugs to me.

For future reference, a case like this does not need a small test case program
supplied.  It is sufficient if a command line using locale or suchlike is a good
test case.

Thanks for the info. The maintainer informed me that this was committed to gnulib.

The attached patch does not only not apply, even after fixing it up it doesn't
solve the problem.  Either it never worked or the gnulib version is sufficiently
different.  Please provide a correct patch.

no response

This bug report is still valid and the bug afflicts rawhide's
glibc-2.12.90-1.x86_64. Running this example from the manual still infloops:

$ cat k.c; gcc k.c; ARGP_HELP_FMT=rmargin=2 ./a.out --help > /dev/null
#include <argp.h>
int main (int argc, char **argv)
{
  argp_parse (0, argc, argv, 0, 0, 0);
  return 0;
}
^C

FYI, the referenced patch ensures that the new function, validate_uparams, is
used to reject invalid parameters.  Rerunning my example, built against the
version in gnulib produces this:

a.out: ARGP_HELP_FMT: rmargin value is less than or equal to short-opt-col

Still not fixed in master.

If a program uses options with OPTION_DOC flag, ARGP_HELP_FMT is able to crash it:

$ cat ./example.c 
#include <argp.h>

char doc[] = "Argp example\vThis part of the documentation comes *after* the options";

struct argp_option options[] = { {"Doc option",0,0,OPTION_DOC}, {0} };

error_t parse_opt (int key, char *arg, struct argp_state *state) {
  switch (key) {
    default: return ARGP_ERR_UNKNOWN;
  }
  return 0;
}

struct argp argp = { options, parse_opt, "", doc };

int main (int argc, char **argv) {
  argp_parse (&argp, argc, argv, 0, 0, 0);
  return 0;
}

$ gcc -Wall ./example.c

$ ./a.out --help
Usage: a.out [OPTION...] 
Argp example

  Doc option
  -?, --help                 Give this help list
      --usage                Give a short usage message

This part of the documentation comes *after* the options

$ ARGP_HELP_FMT=opt-doc-col=2,rmargin=12 ./a.out --help
            Usage:
            a.out            
            [OPTION...]            


rgp example

  Doc
  option
Segmentation fault (core dumped)