Ask a Question related to UNIX Programming, Design and Development.
-
np_rpr #1
getopt in linux
hi all,
i am trying to use the getopt call of glibc in linux for parsing my
command. What i am noticing that this function doesn't return to some of
the options.I tried to understand more ab''t this in man page, but I
still have some doubts :
- does get opt look at all the arguments or does it neglect some of
these
e.g.1) char **op1=command -a arg1 -b arg2 -c arg3
2)char **op2= -a arg1 -b arg2 -c arg3 -d arg4
when used 'op2' getopt neglected the very first arg1 with -a option and
when i used 'op1' it recognized all.
can anyone please clearify this and is there any source to find more
detail of this call as man page is quite confusing.
thanks,
np
--
Posted via [url]http://dbforums.com[/url]
np_rpr Guest
-
Getopt::Std question
When using Getopt::Std, if I use: getopts('c:'); ....and the user specifies the -c flag but fails to specify a parameter for the flag, such... -
Getopt::Simple V 1.47
The pure Perl module Getopt::Simple V 1.47 is available immediately from CPAN, and from http://savage.net.au/Perl-modules.html. On-line docs,... -
Using Getopt::Std
Hi, i am using the Getopt::Std package in my code. use Getopt::Std; getopts('s:'); $a = $opt_s -
using Getopt with subroutines
Hello, I have a subroutine that is contained within its own module and package. It currently takes 7 different arguments, but only 2 of them are... -
Getopt module
Deb wrote: Hello, No, you don't have strictures enabled (but you should have.) You are getting a warning because you have warnings enabled.... -
Floyd Davidson #2
Re: getopt in linux
np_rpr <member33486@dbforums.com> wrote:
The parameter list for getopt() looks like,>hi all,
>i am trying to use the getopt call of glibc in linux for parsing my
>command. What i am noticing that this function doesn't return to some of
>the options.I tried to understand more ab''t this in man page, but I
>still have some doubts :
>- does get opt look at all the arguments or does it neglect some of
> these
> e.g.1) char **op1=command -a arg1 -b arg2 -c arg3
> 2)char **op2= -a arg1 -b arg2 -c arg3 -d arg4
>
>when used 'op2' getopt neglected the very first arg1 with -a option and
>when i used 'op1' it recognized all.
int getopt(int argc, char * const argv[], const char *optstring);
Note the second parameter is not a pointer to pointer to char,
but rather an array of pointers to char (or, more easily
understood, it is an array of pointers to strings). It should
be declared as char opt1[], not char **op1.
It is of course intended to be the argv array from
main(int argc, char *argv[])
Here is what the C Standard says that array is supposed to be:
"If the value of argc is greater than zero, the string
pointed to by argv[0] represents the program name;
argv[0][0] shall be the null character if the program name
is not available from the host environment. If the value of
argc is greater than one, the strings pointed to by argv[1]
through argv[argc-1] represent the program parameters."
Obviously you most certainly do expect the first element of the
array to be skipped over by the getopt() function, because it is
the program name, not a command line argument.
I would expect it to be explained in any C tutorial aimed at a>can anyone please clearify this and is there any source to find more
>detail of this call as man page is quite confusing.
unix environment.
--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) [email]floyd@barrow.com[/email]
Floyd Davidson Guest
-
Matthew Hails #3
Re: getopt in linux
Floyd Davidson wrote:
Ok, there's some truth in that. Let me explain my "terms" more fully:> Matthew Hails <matthew@nospam.nospam> wrote:>> >Floyd Davidson wrote:> >> >> The parameter list for getopt() looks like,
> >>
> >> int getopt(int argc, char * const argv[], const char *optstring);
> >>
> >> Note the second parameter is not a pointer to pointer to char,
> >> but rather an array of pointers to char (or, more easily
> >> understood, it is an array of pointers to strings). It should
> >> be declared as char opt1[], not char **op1.
> >To be pedantic ...
> I don't think you actually said anything different than what
> I did, except that you are applying the same terms to different
> objects than I did.
The formal parameter type is:
pointer to pointer to char
The actual argument expected is:
pointer to array of pointer to char
The variable declared in the calling function is likely to be:
array of pointer to char
I disagree! It may look like it is, because it uses [], but really it's a>> >Technically the second parameter *is* a pointer to (a const) pointer to
> >char.
> Not in the prototype/declaration above!
pointer type, not an array. Try passing an array of pointers to char into
a function with that prototype and I think you'll find that it always
passes in a pointer to the array, not the array itself. Try passing in a
pointer to pointer to char, and I think you'll find that it is passed in
successfully.
Yes, I agree. It's just that you made it using a statement which I thought>> > C allows you to declare the parameter using array syntax, but it
> >actually is a pointer type. The reason (be it good or bad) for using the
> >array syntax is to indicate that the caller should pass in a pointer to
> >an array (of pointers to char), rather than just a pointer (to pointer
> >to char).
> Well... isn't that exactly the point that I was making?
might be misleading.
Yes. Sorry - I should have said in my previous post that your original>> >Of course, when you pass an array of pointer to char to the
> >function, it will be converted to a pointer to its first element, that
> >is, of type pointer to an array of pointer to char.
> >(Sorry about all the pointers :-)
> >
> >It can be declared as any of the following (the array sizes and values
> >are examples only):
> >
> > char * opt1[2];
> > char ** opt2; /* Storage allocated/assigned later */
> > char * const opt3[] = { "a", "b" };
> > char * const * opt4 = opt3;
> True, but as noted, in this particular instance what it actually has
> to be is is a pointer to an array. My reason for pointing that out
> was because the pseudo code that was posted by the OP didn't make
> it clear which it was.
reply was, in general, just what the OP needed.
--
Matthew Hails <matthew@hails.org.uk>
Matthew Hails Guest
-
Matthew Hails #4
Re: getopt in linux
Floyd Davidson wrote:
You are nearly(*) correct in a sense. (Sadly I wandered into this> Matthew Hails <matthew@nospam.nospam> wrote:
>>> >> >>Floyd Davidson wrote:> >> >>>> Matthew Hails <matthew@nospam.nospam> wrote:
> >>
> >>>>> >Floyd Davidson wrote:
> >>>
> >>>>>> >> The parameter list for getopt() looks like,
> >>>>>> >>
> >>>>>> >> int getopt(int argc, char * const argv[], const char *optstring);
> >>>>>> >>
> >>>>>> >> Note the second parameter is not a pointer to pointer to char,
> >>>>>> >> but rather an array of pointers to char (or, more easily
> >>>>>> >> understood, it is an array of pointers to strings). It should
> >>>>>> >> be declared as char opt1[], not char **op1.
> >>>
> >>>>> >
> >>>>> >To be pedantic ...
> >>
> >>>>
> >>>> I don't think you actually said anything different than what
> >>>> I did, except that you are applying the same terms to different
> >>>> objects than I did.> >>
> >>Ok, there's some truth in that. Let me explain my "terms" more fully:
> >>
> >>The formal parameter type is:
> >> pointer to pointer to char
> If you mean the parameter list of the declaration, *look* at the
> above declaration, which is "char * const argv[]". That is a
> pointer to an array of pointers to char, not a pointer to
> pointer to char. (I'm ignoring the "const" in this discussion
> to reduce confusion.)
discussion claiming to be pedantic, but haven't been pedantic enough in my
explanations). The second parameter is declared as an array of pointer to
char, but is immediately converted to a pointer to pointer to char. (I
think we're agreed to ignore the "const" for this discussion!). The C99
standard says:
"A parameter declared to have array or function type is converted to a
parameter with a pointer type as described in 6.9.1." [6.5.2.2]
"A declaration of a parameter as 'array of type' shall be adjusted to
'qualified pointer to type' ... " [6.7.5.3]
"On entry to the function, the size expressions of each variably
modified parameter are evaluated and the value of each argument
expression is converted to the type of the corresponding parameter as if
by assignment. (Array expressions and function designators as arguments
were converted to pointers before the call.)" [6.9.1]
So we see that:
(1) The declaration of the parameter is converted from "array of pointer to
char" to "pointer to pointer to char".
(2) On calling the function, the actual argument, if of type "array of
pointer to char", is converted to "pointer to pointer to char" before
being passed.
Indeed, if I look on my machine (vanilla RedHat 8.0), the man page has
the second parameter as "char * const argv[]" (the same as you quoted),
but in the system header files it is declared as:
extern int getopt (int ___argc, char *const *___argv, const char *__shortopts);
True. What I said there wasn't strictly correct. (But see above).>> >> >>>>> >Technically the second parameter *is* a pointer to (a const) pointer to
> >>>>> >char.
> >>
> >>>>
> >>>> Not in the prototype/declaration above!> >>
> >>I disagree! It may look like it is, because it uses [], but really it's a
> Array types are distinct from pointer types. That really is an
> array type, because it does use the [] syntax.
I agree!> Array objects and pointers objects are NOT the same thing.
Ok, I concede that the formal parameter does have array type. But - it is>> >>Try passing an array of pointers to char into
> First, for the parameter list in a declaration, when comparing
> functions for compatibility, yes the array type will first be
> converted to a pointer type before determining if the types are
> compatible.
>
> Second, when a function call is made, the argument list holds
> the identifiers of objects listed, and that in this case would
> include the name for an array object. However, before the
> actual function call is made the identifier for the array object
> will be converted to a pointer to the first element of that
> object.
>
> None of which means that "really it's a pointer type, not an
> array". It is an array, and in specific situations it is
> specifically converted to a pointer.
converted into a pointer type before it can have any effect on a caller of
the function.
Argghhh - impaled on my own words :-)> I was being pedantic. :-)
Perhaps I can try and summarise:
1. I agree that you were correct in saying that:
The formal parameter really does have array type.
(And I was wrong to say that it *does have* pointer type)
2. However, my contention is (and this is how I should have (pedantically!)
explained it the first time):
The formal parameter is converted to a pointer type, and therefore the
array type declaration has no more effect than documenting that the
function expects the pointer to access an array rather than a single
object.
This is why glibc can merrily document that it is an array type but
really declare it as a pointer type.
(*) I say "nearly", because you said "pointer to an array of pointers to
char". If we're discussing exactly what the declared type is, then it's
not a pointer type yet, but simply an "array of pointers to char".
Of course, later on in the discussion you do say it's an array type, so
I'll assume that's what you meant in this first instance.
(Phew! :-)
--
Matthew Hails <matthew@hails.org.uk>
Matthew Hails Guest



Reply With Quote

