apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: [PATCH] apr_getopt_long interface update and interleaving support
Date Sat, 25 Nov 2000 23:15:44 GMT
On Fri, Nov 24, 2000 at 05:10:08PM -0600, Karl Fogel wrote:
> 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.

"Come over to the Const Side, Luke..."

> 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.

If we add const to the interface, then we can't cast away the const. We have
to make a copy of the array [that we'll be permuting]. This is what the code
does now.

If we attempted to cast away the const and then change it, we could core
dump. See my example with the "static const * const cmdline[]". Everything
about that is const, so No Changes Allowed. :-)

> Does the above declaration still permit permutation of the array?

Nope.

> (Apologies; I'm rereading my K&R and still not fully understanding
> what the above does.)

As said elsewhere, K&R doesn't have "const", so I don't know that you'd find
it in there :-)  [ of course, if they updated for ANSI... well. ]

> 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.

We also need #3 to be const. If you attempt to modify those on Linux, you
get a core dump. The kernel places the string contents in a read-only
segment. Strangely, the array of pointers (#2) is modifiable.

There is not much sense in adding const to argv itself (#1) since that is
call-by-value anyways. The function (implementation) can change that value
at will, without any impact on the caller.

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

Consider yourself beaned :-). But it is understandable. As Brane points out,
this stuff can be a bit tricky to wrap your head around. Following the "read
from right to left" rule is the easiest way to read something declared as
"const char * const *argv". When [] gets in there, too, then duct tape your
head before reading it; otherwise, your head could blow up. I've lost two
friends that way.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message