Re: [help-gengetopt] make cmd_line_list and cmd_line_list_tmp static?

[Andre Noll]

On 10:20, Lorenzo Bettini wrote:

> >Is there a reason why gengetopt-2.15 generates non-static versions of
> >struct cmd_line_list and struct cmd_line_list_tmp?
> >
> >If these two were static it would be possible to link more than one
> >xyz.cmdline.o into a single executable.
> >
> >Regards
> >Andre
> 
> Dear Andre
> 
> actually I had never thought about this possibility, and you're right: 
> there's no reason why these structs should be non-static, so I'll make 
> them static in the next release.

Thank you very much!

Here's another small issue:

My application [1] has several subcommands, much like lvm2, ftp and
many other shell-like programs. Each subcommand comes with its own
syntax and command line parser.

Compiling and linking works like a charm after making the above two
variables static, but there is a run-time problem: As the user may
execute the same subcommand many times, it is neccessary to invoke
the same command line parser more than once with completely different
values of argc and argv.

The problem is that gengetopt generates code that always sets the
extern variable "optind" to one before entering the loop which calls
getopt_long(). According to POSIX, this instructs getopt_long() to
continue to parse those command line options that were passed to it
during the previous call.

So getopt_long() internally keeps pointers to memory determined by
argc, argv and accesses this memory in subsequent calls if the previous
call did not parse all of the command line options. This happens for
example if the command line of the previous run contained the string
"--".  In my case, however, that memory is long gone at the time the
subcommand is executed for the second time.

In other words: The application crashes somewhere in glibc as soon
as the same subcommand is called for the second time.

So I replaced "optind = 1" by "optind = 0" in the generated code which
tells getopt_long() to discard any internal pointers and restart from
scratch with the _given_ argc, argv, rather than continue to parse
the command line from the _previous_ run.

As this solved all of my problems and I can not see any drawbacks of
this approach either, I'd suggest to let gengetopt generate "optind =
0" instead of "optind = 1".

So many words for a request to change a single bit :)

Regards
Andre

[1] paraslash -- www.parashlash.org
-- 
Jesus not only saves, he also frequently makes backups