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 _______________________________________________ Help-gengetopt mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gengetopt
