[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] apr_getopt_long interface update and interleaving support

From: Greg Stein <gstein_at_lyra.org>
Date: 2000-11-26 00:15:44 CET

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/
Received on Sat Oct 21 14:36:15 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.