help-gengetopt
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Lorenzo Bettini
Subject: Re: [help-gengetopt] make cmd_line_list and cmd_line_list_tmp static?
Date: Sun, 19 Feb 2006 12:37:49 +0100
User-agent: Debian Thunderbird 1.0.7 (X11/20051017)

I've uploaded a candidate 2.16 release with this feature:

http://rap.dsi.unifi.it/~bettini/gengetopt-2.16-rc.tar.gz

could you please try it and tell me if this satisifies your request?

by the way, could you please send me some code snippet that uses subcommands (so that I can set up the documentation right)?

I hope to hear from you soon!

cheers
        Lorenzo

Andre Noll wrote:
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


--
+-----------------------------------------------------+
|  Lorenzo Bettini          ICQ# lbetto, 16080134     |
|  PhD in Computer Science                            |
|  Dip. Sistemi e Informatica, Univ. di Firenze       |
|  Florence - Italy        (GNU/Linux User # 158233)  |
|  Home Page        : http://www.lorenzobettini.it    |
|  http://music.dsi.unifi.it         XKlaim language  |
|  http://www.purplesucker.com Deep Purple Cover Band |
|  http://www.gnu.org/software/src-highlite           |
|  http://www.gnu.org/software/gengetopt              |
|  http://www.lorenzobettini.it/software/gengen       |
|  http://www.lorenzobettini.it/software/doublecpp    |
+-----------------------------------------------------+




reply via email to

[Prev in Thread] Current Thread [Next in Thread]