Re: getopt in linux
From: Floyd Davidson (floyd_at_barrow.com)
Date: 07/20/03
- Next message: Marc Rochkind: "Re: Ambiguity in SysV IPC keys"
- Previous message: ixtahdoom: "bi-directional IPC / pipes / when to close??"
- In reply to: Matthew Hails: "Re: getopt in linux"
- Next in thread: Matthew Hails: "Re: getopt in linux"
- Reply: Matthew Hails: "Re: getopt in linux"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: 19 Jul 2003 14:04:56 -0800
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.)
>The actual argument expected is:
> pointer to array of pointer to char
This is a different object than the above, but they must be
"compatible types". The declaration could be a different but
compatible type, and all would still work. But what purpose
would that serve?
>The variable declared in the calling function is likely to be:
> array of pointer to char
It may or may not be, but regardless of what it is at that
point, it will be converted by the compiler, before the called
function executes. And regardless of that conversion, it is
going to be treated by the called function in this case as an
array of pointers.
>> >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.
Array objects and pointers objects are NOT the same thing.
>pointer type, not an array.
No, it is an array type. And parameters in declarations are not
passed, so comparing that to a function call has no meaning.
>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.
>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.
But I didn't suggest in any way that a function can directly
pass an array.
>> > 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?
>
>Yes, I agree. It's just that you made it using a statement which I thought
>might be misleading.
I was being pedantic. :-)
>> >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.
>
>Yes. Sorry - I should have said in my previous post that your original
>reply was, in general, just what the OP needed.
-- Floyd L. Davidson <http://web.newsguy.com/floyd_davidson> Ukpeagvik (Barrow, Alaska) floyd@barrow.com
- Next message: Marc Rochkind: "Re: Ambiguity in SysV IPC keys"
- Previous message: ixtahdoom: "bi-directional IPC / pipes / when to close??"
- In reply to: Matthew Hails: "Re: getopt in linux"
- Next in thread: Matthew Hails: "Re: getopt in linux"
- Reply: Matthew Hails: "Re: getopt in linux"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
