Re: why cannot assign to function call

rurpy@xxxxxxxxx <rurpy@xxxxxxxxx> 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]
.

Relevant Pages

  • Re: Rules for valid pointer deallocation
    ... Here, you pointer isn't ... the array section array_ref. ... The Fortran standard does not say that the whole array ...
    (comp.lang.fortran)
  • Re: multi dimensional arrays as one dimension array
    ... please - where does the standard say that such a conversion ... Pointer conversion yields a pointer to the same object as ... exist only where there are array declarations. ...
    (comp.lang.c)
  • Re: Using &array with scanf
    ... >>> a pointer to char and gets a pointer to an array of 20 char. ... It's also wrong because it doesn't check the return value of scanf. ... >>> What I don't know is where the standard tells me conclusively that it's ...
    (comp.lang.c)
  • Re: Out-of-bounds nonsense
    ... we've been discussing the accessing of array elements ... Both the C Standard and the C++ Standard necessitate that the four int's be ... 6.5.6p8 of the C standard says about C pointer arithmetic. ... is 'int' that contains the object it points at is the sub-array a. ...
    (comp.std.c)
  • Re: Out-of-bounds nonsense
    ... we've been discussing the accessing of array elements ... Both the C Standard and the C++ Standard necessitate that the four int's be ... 6.5.6p8 of the C standard says about C pointer arithmetic. ... is 'int' that contains the object it points at is the sub-array a. ...
    (comp.std.c)