[Top][All Lists]

[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: Tue, 02 May 2006 11:37:07 +0200
User-agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)

Andre Noll wrote:
On 21:04, Lorenzo Bettini wrote:

Andre Noll wrote:

Unfortunately, "optind = 0 means initialize" seems to be a glibc
feature that is not backed up by POSIX. So I agree that gengetopt
should not rely on it. Which leaves the question how to tell getopt
to discard any internal pointers in a portable way.

I guess the right thing to do is to never free arguments passed to getopt_long if another call has to be made: this seems to never be safe (even because getopt_long can rearrange the elements, as documented).

That's bad news to me as my application reads one line at a time from
a client, calls a suitable parser (depending on the first word in
the line), does some work and starts over. So the same parser can be
called arbitrary often, and the command line options of the previous
call are completely irrelevant for the next call. What should I do
in this situation?

that's not a problem as long as you don't free memory...

indeed the problem is only the memory where the command line arguments are store, while there's no problem in freeing the strings in the struct (for the moment this is still not safe, since freeing the struct also releases internal memory where the command line arguments are stored, in case of the string parser, but I'm working on this)

I uploaded a newer version here

I still haven't documented the use of multiple parsers but there's the test test_multiple_parsers that can be taken as an example of usage of three parsers.

there's the new parser function that can be generated with the gengetopt command line

-S, --string-parser         generate a string parser (the string
                                contains the command line)

see the test test_multiple_parsers.c

Nice. That saves some work as the application no longer has to split
the command line. However, I fail to see how this solves the above
problem. What I need is something like the following pseudo code:

  while (read line from client(line)) {
        if (first word of line is "first_cmd")
                if (test_first_cmdline_cmd_parser_string(line + 
                                &first_args_info, "first_cmd") == 0) {

This does not work for me because glibc's getopt internally keeps
a pointer to the command line during the first call and uses this
pointer during the second call. At that time the pointer is either

mhh..., no this should not happen: in the string parser generated by gengetopt, the line you pass (i.e., its memory) is NOT passed to getopt_long: the string parser allocates brand new memory (just to avoid problems with this behavior of getopt_long, so your line is not touched (you can even free it if you want).

no longer valid (in case "line" gets dynamically allocated and freed
after do_work()), or points to some random place in "line" (if "line"
is a static buffer which has new contents).

Of course I switched back to optind = 1

Of course, that made paraslash's grab command stop working ;)

mhh... didn't we solve this problem?
I thought the problems were due to the fact that the passed memory was not well formed, but now, with the string parser it should work, shouldn't it?

I hope to hear from you soon

|  Lorenzo Bettini          ICQ# lbetto, 16080134     |
|  PhD in Computer Science                            |
|  Dip. Sistemi e Informatica, Univ. di Firenze       |
|  Florence - Italy        (GNU/Linux User # 158233)  |
|  Home Page        :    |
|         XKlaim language  |
| Deep Purple Cover Band |
|           |
|              |
|       |
|    |

reply via email to

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