Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.std.c > #6579 > unrolled thread

Re: Function calls

Back to article view | Back to comp.std.c

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Function calls Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-10-04 19:21 -0700
    Re: Function calls James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-10-05 20:50 -0700
      Re: Function calls Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-10-06 05:38 -0700
        Re: Function calls James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-10-06 18:04 -0700
          Re: Function calls Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-10-08 15:30 -0700

#6579 — Re: Function calls

ram@zedat.fu-berlin.de (Stefan Ram) writes:

>   A recent draft of the C specification says about "return":
>
> |A return statement terminates execution of the current
> |function and returns control to its caller.
>
>   . There's also a section "Function calls" in a recent draft.
>   I expect that this section says something similar, to the effect that
>   during the evaluation of a function call, control is transferred to
>   the called function, but I was not able to find such wording!

AFAICT the C standard does not say explicitly that a function
call gives or transfers control to the function being called.
It has been pointed out that the standard does say that calling
a function suspends execution of the current block.

Considering those facts, do you think there is a problem with
the current wording used in the standard?  If you do, what
would you say the problem is, and why is it a problem?

[toc] | [next] | [standalone]

#6580

On Wednesday, October 4, 2023 at 10:21:30 PM UTC-4, Tim Rentsch wrote:
> r...@zedat.fu-berlin.de (Stefan Ram) writes: 
> 
> > A recent draft of the C specification says about "return": 
> > 
> > |A return statement terminates execution of the current 
> > |function and returns control to its caller. 
> >
> > . There's also a section "Function calls" in a recent draft. 
> > I expect that this section says something similar, to the effect that 
> > during the evaluation of a function call, control is transferred to 
> > the called function, but I was not able to find such wording!
> AFAICT the C standard does not say explicitly that a function 
> call gives or transfers control to the function being called.

Section 6.9.1 is about function definitions,. while 6.5.2.2 is about
function calls, but 6.9.1 has several paragraphs of specification about
what happens when the function is called, and the relevant one is:

"After all parameters have been assigned, the compound statement
that constitutes the body of the function definition is executed." (6.9.1p11).

[toc] | [prev] | [next] | [standalone]

#6582

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On Wednesday, October 4, 2023 at 10:21:30?PM UTC-4, Tim Rentsch wrote:
>
>> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>>
>>> A recent draft of the C specification says about "return":
>>>
>>> |A return statement terminates execution of the current
>>> |function and returns control to its caller.
>>>
>>> . There's also a section "Function calls" in a recent draft.
>>> I expect that this section says something similar, to the effect that
>>> during the evaluation of a function call, control is transferred to
>>> the called function, but I was not able to find such wording!
>>
>> AFAICT the C standard does not say explicitly that a function
>> call gives or transfers control to the function being called.
>
> Section 6.9.1 is about function definitions,. while 6.5.2.2 is
> about function calls, but 6.9.1 has several paragraphs of
> specification about what happens when the function is called, and
> the relevant one is:
>
> "After all parameters have been assigned, the compound statement
> that constitutes the body of the function definition is executed."
> (6.9.1p11).

That is one relevant paragraph, but not the only relevant paragraph.
Paragraph 10 of that section says

    On entry to the function, the size expressions of each variably
    modified parameter are evaluated and the value of each argument
    expression is converted to the type of the corresponding
    parameter as if by assignment. (Array expressions and function
    designators as arguments were converted to pointers before the
    call.)

What we are looking for is something that says the function is
"entered", that is, that control is transferred.  It appears the
C standard doesn't actually say that.  In section 6.5.2.2, which
describes function call expressions, the standard doesn't even
explicitly say that a function call expression will call the
function.  The word "call" is used often in 6.5.2.2, but always
as a noun, never a verb.  So 6.5.2.2 says a lot about function
calls, but never explicitly says that one takes place.

I expect no one is confused or unsure about what semantics are
intended for a function call expression.  The question being
asked is about whether the C standard does or should say that a
transfer of control takes place (and if so, how explicitly).
AFAICT the C standard makes no explicit statement that a function
call expression causes a transfer of control, i.e., that at
runtime the called function is "entered".  What text in the
standard says that a function call expression causes a transfer
of control to take place?  Or isn't there one?

[toc] | [prev] | [next] | [standalone]

#6583

On Friday, October 6, 2023 at 8:38:10 AM UTC-4, Tim Rentsch wrote:
> James Kuyper <james...@alumni.caltech.edu> writes:
> > On Wednesday, October 4, 2023 at 10:21:30?PM UTC-4, Tim Rentsch wrote: 
...
> >> AFAICT the C standard does not say explicitly that a function 
> >> call gives or transfers control to the function being called. 
> > 
> > Section 6.9.1 is about function definitions,. while 6.5.2.2 is 
> > about function calls, but 6.9.1 has several paragraphs of 
> > specification about what happens when the function is called, and 
> > the relevant one is: 
> > 
> > "After all parameters have been assigned, the compound statement 
> > that constitutes the body of the function definition is executed." 
> > (6.9.1p11).
> That is one relevant paragraph, but not the only relevant paragraph. 
> Paragraph 10 of that section says 
> 
> On entry to the function, the size expressions of each variably 
> modified parameter are evaluated and the value of each argument 
> expression is converted to the type of the corresponding 
> parameter as if by assignment. (Array expressions and function 
> designators as arguments were converted to pointers before the 
> call.) 

Yes, I mentioned that - "several paragraphs of specification about
what happens when the function is called".

> What we are looking for is something that says the function is 
> "entered", that is, that control is transferred.

I find it confusing that you think something more needs to be
specified. The standard specifies that the compound statement
that constitutes the body of the function gets executed. Could you
explain how that differs from having control transferred to the
function? Please give an example of what it would mean to have
the compound statement executed without transferring control. To
me, execution of the compound statement is what I want to have
happen. It may be a failure of my imagination, but I can't imagine
what it would mean for that to happen without transferring control,
but if it could, I also can't imagine caring.

[toc] | [prev] | [next] | [standalone]

#6584

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On Friday, October 6, 2023 at 8:38:10?AM UTC-4, Tim Rentsch wrote:
>
>> James Kuyper <james...@alumni.caltech.edu> writes:
>>
>>> On Wednesday, October 4, 2023 at 10:21:30?PM UTC-4, Tim Rentsch wrote:
>
> ...
>
>>>> AFAICT the C standard does not say explicitly that a function
>>>> call gives or transfers control to the function being called.
>>>
>>> Section 6.9.1 is about function definitions,. while 6.5.2.2 is
>>> about function calls, but 6.9.1 has several paragraphs of
>>> specification about what happens when the function is called, and
>>> the relevant one is:
>>>
>>> "After all parameters have been assigned, the compound statement
>>> that constitutes the body of the function definition is executed."
>>> (6.9.1p11).
>>
>> That is one relevant paragraph, but not the only relevant paragraph.
>> Paragraph 10 of that section says
>>
>> On entry to the function, the size expressions of each variably
>> modified parameter are evaluated and the value of each argument
>> expression is converted to the type of the corresponding
>> parameter as if by assignment.  (Array expressions and function
>> designators as arguments were converted to pointers before the
>> call.)
>
> Yes, I mentioned that - "several paragraphs of specification about
> what happens when the function is called".

Specificaly, paragraphs 10, 11, and 12 give the semantics for when
a function definition is elaborated.  Note that the Standard does
not say that these paragraphs are about what happens when the
function is called, but what happens when the function is entered.
It may be that the intention is to say what happens when the
function is called, but the Standard doesn't say that.  Paragraph 10
starts "On entry ...";  it does not say "On being called ...".

>> What we are looking for is something that says the function is
>> "entered", that is, that control is transferred.
>
> I find it confusing that you think something more needs to be
> specified.

I never said I think that.  My guess is you didn't give full
attention to the second paragraph of my first posting (and which
you left out of your reply), which makes clear that I am asking
questions of the OP, and not stating a position of my own.  I
don't have a dog in this fight.

> The standard specifies that the compound statement that
> constitutes the body of the function gets executed.

No, it doesn't.  What the Standard does say is that the function
body (i.e., the compound statement that constitutes the body
thereof) gets executed /if and when the function is entered/.
No entry, no execution.  The issue is Does the Standard say the
function is entered (or called)?  Apparently the Standard does
not explicitly say that.

Note that every other state-changing construct (or at least those I
could think of:  ++, --, assignment, if(), switch(), for(), do,
while(), goto, break, continue, and most notably return) describe
their semantics using a transitive verb (sometimes using the passive
voice, but a transitive verb nonetheless).  The semantic description
of function call expressions does not use any such constructions for
the action of calling the function (although there are several
transitive verbs for actions that take place /before/ calling the
function).  Because the description of return says "A return
statement terminates execution of the current function and returns
control to its caller", it isn't surprising that some people expect
to find some sort of similar wording about transferring control in
the description of semantics for function call expressions (and in
particular the OP did have such an expectation).  But there isn't
any.

> Could you explain how that differs from having control transferred
> to the function?  Please give an example of what it would mean to
> have the compound statement executed without transferring control.

This question is moot because it starts from a false assumption.

> To me, execution of the compound statement is what I want to have
> happen.

The question under discussion is about what the C standard says,
not about what anyone wants or expects.  Everyone, or at least
every C programmer, expects and wants a function body to be
executed when a function call expression is evaluated - there is
no disagreement about that.

> It may be a failure of my imagination, but I can't imagine what it
> would mean for that to happen without transferring control, but if
> it could, I also can't imagine caring.

If you get to a point where a conversation doesn't make sense, you
might want to go back and take another look at earlier comments,
to see if there is a point where assumptions on the two sides
diverged, either because someone didn't understand what the other
party was saying or because what someone was trying to say wasn't
said very well and may have been misinterpreted.  If that has
happened it's unlikely any progress will be made until the
divergence has been identified and somehow reconciled.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.std.c

csiph-web