ru...@yahoo.com <ru...@yahoo.com> wrote:
> But if you'll note, I said "if ..." referring to a couple of
> hypothetical C-like languages, so your chapter-and-verse quote from
> the standard, while interesting and appreciated, was basically
> irrelevant.
Ah, what you actually said was still quoted above (thanks):
: v can be used as an array reference, e.g. "v[1] = 23" exactly as in
: the pass-by-reference fortran example. And v can also be used as a
: local variable and reassigned.
:
: If the first option was the only one, would you not say C was
: definitely pass-by-reference (for arrays)?
I must have been reading too quickly and I missed the conditional here.
I'm terribly sorry. :-(
Answering the question as posed, rather than mis-read: I think the
sizeof business would still indicate that a pointer was being passed.
If the language also forbade sizeof on array-type arguments and passing
array as arguments to functions expecting pointers, then I'd say you'd
have a point. But I'm not sure I'd agree that such a language was
`C-like' -- the bizarre behaviour of arrays is one of the language's
most distinctive features!
> >> > Also, notice that arrays in expressions turn into pointers in the same
> >> > way, so function argument passing works the same way as assignment -- a
> >> > hallmark of pass-by-value.
> >>
> >> Not in all expressions as you yourself mentioned:
> >> int a[10], *ap;
> >> sizeof a;
> >> sizeof ap;
> >
> > Well done, you've pedantically picked up on the lapse in the first part
>
> It isn't pedantic. It is the only thing (IFAIK) that allows one to
> talk about variables of an array type (as opposed to only pointers).
You can talk about /variables/ of array type, but not /expressions/ of
array type (except in very limited circumstances, as operands of sizeof
or &).
> Actually I've already downloaded a C89/90 standard draft in the hope
> that an earlier version would be simpler. Since C's behavior vis
> "call-by-x" is (I presume) unchanged back to K&R, whatever it said
> about it should be confirmable by any ealier versions descriptions of
> C.
It should be; but you may have to adjust the clause numbers I'm citing.
Also, the earlier version of the standard didn't have numbered
paragraphs, which makes citing specific bits more tedious.
> But more importantly, we seem to be talking at cross purposes.
We might be...
[snip]
> So all the quoting of the C standard in the world does not address the
> issue: can C's array passing be described (modeled) as
> pass-by-reference? I acknowledge that the C standard provides one
> (correct) model in which arrays aren't passed, only pointers by-value.
>
> To address the issue you need to show that an alternate model (array
> passing by-reference for example) is incorrect, i.e. leads it user to
> conclude that a program will behave differently than it does. And of
> course, when such a discrepancy model and behavior is pointed out, the
> proposer of the alternate model will fix it if possible.
I'd claim, in fact, that the proposer of an alternative model bears the
responsibility to prove it correct, i.e., in the case of C, at least
consistent with the official standard.
But I believe that I have indeed shown that the arrays-passed-by-
reference model is incorrect, by demonstrating that the called function
sees the parameter as a freshly allocated pointer and not an array: it
can be assigned (unlike an array); its size is that of a pointer; one
can take its address and manipulate its bit-pattern as if it were a
pointer. Indeed, the standard guarantees that no strictly-conforming C
program can distinguish the parameter from a freshly allocated pointer.
And therefore I can point to my earlier (almost-formal) definitions of
pass-by-value and pass-by-reference to complete the proof: the
allocation of a new variable is inconsistent with pass-by-reference,
while it is consistent with pointer-decay followed by pass-by-value.
Of course, this is contingent on your acceptance of my definitions. But
I don't see anyone else providing sufficiently detailed definitions to
make such proofs, and my definitions seem consistent with the way most
other languages use the terms, so I'm pretty confident that they're
good...
> Many of the responses by you, Joe, and others, have an "of course this
> model is the right one, how could anyone think otherwise" tone to
> them. I hope I have explained clearly why I think that attitude is
> unjustified.
I hope that I've been doing more than that: drawing comparisons with and
borrowing concepts from other languages, attempting to solidify
definitions which otherwise seem to cause controversy, and then drawing
conclusions from these definitions to strengthen my case and weaken
others' cases.
> Finally, and please don't be insulted by this, but to me and many
> readers, you are a bunch on glowing dots on a screen.
As are we all. (Brought to you by Sobering Thought for the Day.)
> I have been using the internet long enough to have any number of times
> read very plausible, authoritative sounding tomes only to find out
> later they were BS, or a least, not as widely accepted as gospel as
> the author proclaimed.
I'm trying very hard not to ask anyone to take my word for things -- it
always makes me uneasy when people are willing to do that, but they seem
to be[1]. Rather, I'm attempting to present my reasoning in a way that
you and others can read and judge for yourselves. If I've failed, then
I'm sorry -- I'm fallible, and my communication skills are somewhere
between imperfect and downright patchy depending on who you talk to.
[1] I work in security. Being asked to take things on trust rubs me up
the wrong way, and I hope that other people react the same way; if
they don't, I get nervous...
> All that not withstanding, thank you for taking the time to respond in
> the depth you have. I appreciate it and have clarified a lot of my
> thinking on the subject as as result.
-- [mdw]
--
http://mail.python.org/mailman/listinfo/python-list
