apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Fogel <kfo...@galois.collab.net>
Subject Re: [PATCH] apr_getopt_long interface update and interleaving support
Date Fri, 24 Nov 2000 23:10:08 GMT
Greg Stein <gstein@lyra.org> writes:
> So... by stating the parameter is "const char * const *argv", we are saying
> what we intend to do (or not do) with the arguments. And I think we really
> ought to treat it as if those const qualifiers were on there.

I confess I don't understand the nuance of these `const' usages.

The code needs to permute argv; if it can't, we'll have to change the
interface, right?  If Greg H has to cast internally to get something
he can permute, then we might as well not require a const on the
castee in the first place.

Does the above declaration still permit permutation of the array?
(Apologies; I'm rereading my K&R and still not fully understanding
what the above does.)

That is (using the invocation "svn -d foo bar"), we have

   argv --------+
                |
                |
                V
               [pointer1 , pointer2 , pointer3 , pointer4, pointer5]
                   |          |          |          |         |
                   |          |          |          |         |
                   |          |          |          |         |
                   V          V          V          V         V
                  [svn\0]    [-d\0]     [foo\0]    [bar\0]  <NULL>


So there are three things that could be constified:

   1. The variable `argv', which holds a pointer to an array of
      pointers.

   2. The elements of that array, each of which points to a C string.

   3. The elements of a given C string.

If we're constifying #2, then that's a problem for permutation.

Please feel free to bean me if I'm totally missing the point here...

Humility is my strong suit,
(Oh wait),
-K

Mime
View raw message