Sequence Point before actual function call

**Richard Heathfield** · Oct 28 '08, 07:45 AM

Re: Sequence Point before actual function call

coolguyaroundyo u@gmail.com said:

See the below code:
>
void func(int x)
{
printf("%d",x);
}
>
int main()
{
int j=0;
func(j++);
return 0;
}
>
What should be the output?

0, same as the last time you asked.

The C Standard says that there is a sequence point before the actual
function call.

There is.

So, according to me it should have been 1 but I got
0(zero) on my screen.

No, 0 is correct. (a) evaluate expression arguments - the value of j++ is
0; (b) sequence point; (c) function call.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

**Ian Collins** · Oct 28 '08, 07:55 AM

Re: Sequence Point before actual function call

coolguyaroundyo u@gmail.com wrote:

See the below code:
>

Why have you ignored 13 hours worth of replies. Wait, let me guess: a
google poster...

--
Ian Collins

**Default User** · Oct 28 '08, 04:45 PM

Re: Sequence Point before actual function call

Ian Collins wrote:

coolguyaroundyo u@gmail.com wrote:

See the below code:

Why have you ignored 13 hours worth of replies. Wait, let me guess: a
google poster...

Yeah, it went through another outage. What a craptastic system that is.

Brian

**Gordon Burditt** · Oct 29 '08, 01:25 AM

Re: Sequence Point before actual function call

>void func(int x)

>{
>printf("%d",x) ;
>}
>
>int main()
>{
>int j=0;
>func(j++);
>return 0;
>}
>
>What should be the output?

The value returned by j++ is the value of j before the increment
is applied (zero). That value is not affected by later changes to
j.

There are a number of ways for a compiler to generate code for this
expression. It still has to get the returned value correct.

It could increment j first. (and then decrement a copy of j for
the return value). The value returned by j++ is the value of j
before the increment is applied (zero).

It could increment j last (but before the function call. The value
returned by j++ is the value of j before the increment is applied
(zero).

It could return the value of j++ and increment j simultaneously
(given multiple CPUs). The value returned by j++ is the value of
j before the increment is applied (zero).

It could increment the value of a copy of j before returning the
value of j++ but store it back afterwards. The value returned by
j++ is the value of j before the increment is applied (zero).

There are all sorts of other orders things could be done. The value
returned by j++ is the value of j before the increment is applied
(zero).

>The C Standard says that there is a sequence point before the actual
>function call. So, according to me it should have been 1

Don't think that. You would be correct if func() printed j (which
would then likely be a file-scope variable), *NOT* func's first
argument. But that's not what your code does.

The postincrement operator returns the value as it was before
the increment is done. That value in this case is zero.

>but I got
>0(zero) on my screen.

**Phil Carmody** · Oct 29 '08, 10:15 AM

Re: Sequence Point before actual function call

gordon@hammy.bu rditt.org (Gordon Burditt) writes:

>>void func(int x)
>>{
>>printf("%d",x );
>>}
>>
>>int main()
>>{
>>int j=0;
>>func(j++);
>>return 0;
>>}
>>
>>What should be the output?

>
The value returned by j++ is the value of j before the increment

The first time grates.

is applied (zero). That value is not affected by later changes to
j.
>
There are a number of ways for a compiler to generate code for this
expression. It still has to get the returned value correct.

The second grates more.

It could increment j first. (and then decrement a copy of j for
the return value). The value returned by j++ is the value of j

But two on one line has pushed me over the edge.

There is no "returning" of values in the expression 'j++'; it
simply has a value. You don't go anywhere to evaluate it, so you
don't return either. "The value of j++ is ..." is shorter and
more precise.

The value returned by j++
>
return the value of j++
The value returned by j++
>
returning the value of j++
The value returned by j++
>
The value returned by j++
>
The postincrement operator returns the value

Ug.

Phil
--
Christianity has such a contemptible opinion of human nature that it does
not believe a man can tell the truth unless frightened by a belief in God.
No lower opinion of the human race has ever been expressed.
-- Robert Green Ingersoll (1833-1899), American politician and scientist

**Richard Heathfield** · Oct 29 '08, 10:35 AM

Re: Sequence Point before actual function call

Phil Carmody said:

gordon@hammy.bu rditt.org (Gordon Burditt) writes:

<snip>

>The value returned by j++ is the value of j before the increment

>
The first time grates.

[operator 'returning' a value]

<snip>

But two on one line has pushed me over the edge.

Your fall is noted, but it was a wasted gesture. On at least two occasions,
even the Standard itself uses the word "return" to describe the yielding
of a value by an operator. If such terminology is acceptable to ISO, I
don't see why clc should have a problem with it. I recommend that you
review not only the Standard but also your irritability threshold, which
seems inordinately low at present.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

**Phil Carmody** · Oct 29 '08, 01:25 PM

Re: Sequence Point before actual function call

Richard Heathfield <rjh@see.sig.in validwrites:

Phil Carmody said:
>

>gordon@hammy.bu rditt.org (Gordon Burditt) writes:

>
<snip>
>

>>The value returned by j++ is the value of j before the increment

>>
>The first time grates.

>
[operator 'returning' a value]
>
<snip>
>

>But two on one line has pushed me over the edge.

>
Your fall is noted, but it was a wasted gesture. On at least two occasions,
even the Standard itself uses the word "return" to describe the yielding
of a value by an operator.

If my pdf viewer's search function is working correctly, I
couldn't find any in n1256. I looked particularly at section
6.5 Expressions, and it seems that 'result' is used practically
everywhere, with not a 'return' to be seen outside a function-
call context. Would you care to pinpoint these usages to slightly
more accurate resolution than 500+-pages?

If such terminology is acceptable to ISO, I
don't see why clc should have a problem with it.

Do you personally like the usage? Does anyone?

I recommend that you
review not only the Standard but also your irritability threshold, which
seems inordinately low at present.

If you don't want to see my irritation, then that can be diminished
by not sending unsolicited patronising and obnoxiously accusatory
christian propaganda to my personal email account.

Phil
--
Christianity has such a contemptible opinion of human nature that it does
not believe a man can tell the truth unless frightened by a belief in God.
No lower opinion of the human race has ever been expressed.
-- Robert Green Ingersoll (1833-1899), American politician and scientist

**Richard Heathfield** · Oct 29 '08, 02:45 PM

Re: Sequence Point before actual function call

Phil Carmody said:

Richard Heathfield <rjh@see.sig.in validwrites:

>Phil Carmody said:
>>

>>gordon@hammy.bu rditt.org (Gordon Burditt) writes:

>>
><snip>
>>

>>>The value returned by j++ is the value of j before the increment
>>>
>>The first time grates.

>>
>[operator 'returning' a value]
>>
><snip>
>>

>>But two on one line has pushed me over the edge.

>>
>Your fall is noted, but it was a wasted gesture. On at least two
>occasions, even the Standard itself uses the word "return" to describe
>the yielding of a value by an operator.

>
If my pdf viewer's search function is working correctly, I
couldn't find any in n1256.

Then either your search function is not working correctly or those
references have been removed. Nevertheless, they were certainly there in
C89 and they were certainly there in C99 - so that usage of the
terminology has been around for a very long time, whether or not it
remains there at the present moment.

I looked particularly at section
6.5 Expressions, and it seems that 'result' is used practically
everywhere, with not a 'return' to be seen outside a function-
call context. Would you care to pinpoint these usages to slightly
more accurate resolution than 500+-pages?

Here's some context:

C89: 3.3 Expressions
"These operators return values that depend on the internal representations
of integers, and thus have implementation-defined aspects for signed
types."

C99: 6.5 Expressions
"These operators return values that depend on the internal representations
of integers, and have implementation-defined and undefined aspects for
signed types."

C99: 6.5.3.1 "The unary & operator returns the address of its operand."

This phrase is not present, as far as I can tell, in C89, but was
introduced in C99.

>If such terminology is acceptable to ISO, I
>don't see why clc should have a problem with it.

>
Do you personally like the usage? Does anyone?

I don't mind either way. It may not be everyone's cup of tea, but to object
to it smacks of silliness. Terminology is important, but it's hardly so
important as to push you over any edges - and even if the ISO folks no
longer use the term in that way, they used it that way in the Standard for
well over a decade, and (appear) even to have *expanded* its use in the
original ratified version of C99, so it's not as if it's self-evidently
wrong. Dogma has its place, but this isn't that place.

<nonsense snipped>

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

**Phil Carmody** · Oct 29 '08, 03:55 PM

Re: Sequence Point before actual function call

Richard Heathfield <rjh@see.sig.in validwrites:

Phil Carmody said:
>

>Richard Heathfield <rjh@see.sig.in validwrites:

>>Phil Carmody said:
>>>
>>>gordon@hammy.bu rditt.org (Gordon Burditt) writes:
>>>
>><snip>
>>>
>>>>The value returned by j++ is the value of j before the increment
>>>>
>>>The first time grates.
>>>
>>[operator 'returning' a value]
>>>
>><snip>
>>>
>>>But two on one line has pushed me over the edge.
>>>
>>Your fall is noted, but it was a wasted gesture. On at least two
>>occasions, even the Standard itself uses the word "return" to describe
>>the yielding of a value by an operator.

>>
>If my pdf viewer's search function is working correctly, I
>couldn't find any in n1256.

>
Then either your search function is not working correctly or those
references have been removed. Nevertheless, they were certainly there in
C89 and they were certainly there in C99 - so that usage of the
terminology has been around for a very long time, whether or not it
remains there at the present moment.
>

>I looked particularly at section
>6.5 Expressions, and it seems that 'result' is used practically
>everywhere, with not a 'return' to be seen outside a function-
>call context. Would you care to pinpoint these usages to slightly
>more accurate resolution than 500+-pages?

>
Here's some context:
>
C89: 3.3 Expressions
"These operators return values that depend on the internal representations
of integers, and thus have implementation-defined aspects for signed
types."

Can't find an equivalent para.

C99: 6.5 Expressions
"These operators return values that depend on the internal representations
of integers, and have implementation-defined and undefined aspects for
signed types."

n843/n869:
"""
These operators return values
"""

Over half a decade later:

n1256/n1124:
"""
6.5
4. [...] These operators yield values that depend on the internal
representations of integers, and have implementation-defined and
undefined aspects for signed types.
"""

C99: 6.5.3.1 "The unary & operator returns the address of its operand."

This one's got a more interesting history:

n843: (Aug 3 1998)
"""
The result of the unary & (address-of) operator is a pointer to
the object or function designated by its operand.
"""

n869: (Jan 18, 1999)
"""
The unary & operator returns the address of its operand.
"""

n1256/n1124:
"""
6.5.3.2
3. The unary & operator yields the address of its operand.
"""

This phrase is not present, as far as I can tell, in C89, but was
introduced in C99.

I know the intricate diddlings with such documents used to
be documented somewhere public, so in theory the proposer
and date of, and motivation for, the change could be found,
if anyone's interested.

>>If such terminology is acceptable to ISO, I
>>don't see why clc should have a problem with it.

>>
>Do you personally like the usage? Does anyone?

>
I don't mind either way.

I'm genuinely surprised.

It may not be everyone's cup of tea, but to object
to it smacks of silliness. Terminology is important, but it's hardly so
important as to push you over any edges - and even if the ISO folks no
longer use the term in that way, they used it that way in the Standard for
well over a decade, and (appear) even to have *expanded* its use in the
original ratified version of C99, so it's not as if it's self-evidently
wrong. Dogma has its place, but this isn't that place.

In my time teaching, I came to associate the usage of expressions
like "i++ returns the original value of i" with my less capable
students. The ones who understood more about what goes into the
syntax and semantics of computer languages, and how compilers work,
would almost certainly never have used the term. It might be pedantry,
but I think that avoiding the term carries greater precision, and at
no extra cost.

Phil
--
Christianity has such a contemptible opinion of human nature that it does
not believe a man can tell the truth unless frightened by a belief in God.
No lower opinion of the human race has ever been expressed.
-- Robert Green Ingersoll (1833-1899), American politician and scientist

**Keith Thompson** · Oct 29 '08, 04:25 PM

Re: Sequence Point before actual function call

Richard Heathfield <rjh@see.sig.in validwrites:

Phil Carmody said:

[snip discussion of "yield" vs. "return"]

>If my pdf viewer's search function is working correctly, I
>couldn't find any in n1256.

>
Then either your search function is not working correctly or those
references have been removed. Nevertheless, they were certainly there in
C89 and they were certainly there in C99 - so that usage of the
terminology has been around for a very long time, whether or not it
remains there at the present moment.
>

>I looked particularly at section
>6.5 Expressions, and it seems that 'result' is used practically
>everywhere, with not a 'return' to be seen outside a function-
>call context. Would you care to pinpoint these usages to slightly
>more accurate resolution than 500+-pages?

>
Here's some context:
>
C89: 3.3 Expressions
"These operators return values that depend on the internal representations
of integers, and thus have implementation-defined aspects for signed
types."
>
C99: 6.5 Expressions
"These operators return values that depend on the internal representations
of integers, and have implementation-defined and undefined aspects for
signed types."

n1256: 6.5p4:
These operators yield values that depend on the internal
representations of integers, and have implementation-defined and
undefined aspects for signed types.

C99: 6.5.3.1 "The unary & operator returns the address of its operand."

Correction: that's in 6.5.3.2p3.

n1256: 6.5.3.2p3:
The unary & operator yields the address of its operand.

This phrase is not present, as far as I can tell, in C89, but was
introduced in C99.

And n1256 corrected it. As far as I can tell, n1256 *never* refers to
an expression "returning" a value. Functions return values;
expressions yield values.

>>If such terminology is acceptable to ISO, I
>>don't see why clc should have a problem with it.

>>
>Do you personally like the usage? Does anyone?

>
I don't mind either way. It may not be everyone's cup of tea, but to object
to it smacks of silliness. Terminology is important, but it's hardly so
important as to push you over any edges - and even if the ISO folks no
longer use the term in that way, they used it that way in the Standard for
well over a decade, and (appear) even to have *expanded* its use in the
original ratified version of C99, so it's not as if it's self-evidently
wrong. Dogma has its place, but this isn't that place.

I will admit that saying an expression returns, rather than yields, a
value doesn't actually cause any ambiguity; the meaning is clear from
the context. But I do think it's important to use words consistently.
For example, it's nice to be able to say clearly that a function
*returns* a value, and a function call (which is an expression)
*yields* the value returned by the function. I probably wouldn't
bother to post a followup for the sole purpose of correcting "returns"
to "yields", but I'll certainly make an effort to use the terms
consistently myself, and I encourage others to do so as well.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

**Richard Heathfield** · Oct 29 '08, 06:35 PM

Re: Sequence Point before actual function call

Keith Thompson said:

Richard Heathfield <rjh@see.sig.in validwrites:

<snip>

>C99: 6.5.3.1 "The unary & operator returns the address of its operand."

>
Correction: that's in 6.5.3.2p3.

Yes. Thank you.

>
n1256: 6.5.3.2p3:
The unary & operator yields the address of its operand.
>

>This phrase is not present, as far as I can tell, in C89, but was
>introduced in C99.

>
And n1256 corrected it.

Well, changed it, anyway.

As far as I can tell, n1256 *never* refers to
an expression "returning" a value. Functions return values;
expressions yield values.

In n1256, yes, that's true - but it is not true in C89 or unadorned C99.

>

>>>If such terminology is acceptable to ISO, I
>>>don't see why clc should have a problem with it.
>>>
>>Do you personally like the usage? Does anyone?

>>
>I don't mind either way. It may not be everyone's cup of tea, but to
>object to it smacks of silliness. Terminology is important, but it's
>hardly so important as to push you over any edges - and even if the ISO
>folks no longer use the term in that way, they used it that way in the
>Standard for well over a decade, and (appear) even to have *expanded*
>its use in the original ratified version of C99, so it's not as if it's
>self-evidently wrong. Dogma has its place, but this isn't that place.

>
I will admit that saying an expression returns, rather than yields, a
value doesn't actually cause any ambiguity; the meaning is clear from
the context. But I do think it's important to use words consistently.

Operators are remarkably similar to functions anyway. They both perform an
operation (or, if you prefer, a function; or, if you prefer, a series of
zero or more instructions). It is perfectly possible to consider a
programming language entirely bereft of operators, with functions doing
all the work. Similarly, it is possible to consider a programming language
entirely devoid of functions, where operators do all the work (and where
you get to define a new operator if there isn't one that does what you
want!). There's no significant inconsistency in using the word "return" to
describe the act of providing a value at the end of that process, whether
it was provided by an operation or by a function.

For example, it's nice to be able to say clearly that a function
*returns* a value, and a function call (which is an expression)
*yields* the value returned by the function.

I don't think anyone's stopping you saying that, are they?

I probably wouldn't
bother to post a followup for the sole purpose of correcting "returns"
to "yields",

s/correcting/changing/

but I'll certainly make an effort to use the terms
consistently myself, and I encourage others to do so as well.

I do see your point and, in general, I even agree with it. But this, to me,
seems to be taking consistency a little too far. Emerson and all that.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

**Richard Heathfield** · Oct 29 '08, 06:45 PM

Re: Sequence Point before actual function call

Phil Carmody said:

<snip>

In my time teaching, I came to associate the usage of expressions
like "i++ returns the original value of i" with my less capable
students.

Nevertheless, that is a very economical way of describing the value that
post-increment ++ actually provides, and seems to me to be a most capable
description.

The ones who understood more about what goes into the
syntax and semantics of computer languages, and how compilers work,
would almost certainly never have used the term.

In each case, a set of instructions is being carried out and a resulting
value calculated. The distinction is arbitrary.

It might be pedantry,
but I think that avoiding the term carries greater precision, and at
no extra cost.

I'm not (yet) convinced that it's pedantry. (The fact that n1256 dropped
the usage does not make that usage incorrect. It just means n1256 doesn't
use the word in the same way that C99 and C89 do.) Can you convince me?

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

**Keith Thompson** · Oct 29 '08, 06:55 PM

Re: Sequence Point before actual function call

Richard Heathfield <rjh@see.sig.in validwrites:

Keith Thompson said:

[...]

>I will admit that saying an expression returns, rather than yields, a
>value doesn't actually cause any ambiguity; the meaning is clear from
>the context. But I do think it's important to use words consistently.

>
Operators are remarkably similar to functions anyway. They both perform an
operation (or, if you prefer, a function; or, if you prefer, a series of
zero or more instructions). It is perfectly possible to consider a
programming language entirely bereft of operators, with functions doing
all the work. Similarly, it is possible to consider a programming language
entirely devoid of functions, where operators do all the work (and where
you get to define a new operator if there isn't one that does what you
want!). There's no significant inconsistency in using the word "return" to
describe the act of providing a value at the end of that process, whether
it was provided by an operation or by a function.

It's certainly possible to consider such languages. They're not C.

>For example, it's nice to be able to say clearly that a function
>*returns* a value, and a function call (which is an expression)
>*yields* the value returned by the function.

>
I don't think anyone's stopping you saying that, are they?

Of course not. But using the words "return" and "yield"
interchangeably makes it more difficult to say it clearly.

>I probably wouldn't
>bother to post a followup for the sole purpose of correcting "returns"
>to "yields",

>
s/correcting/changing/

No, it's a correction. That's just my opinion, of course, but
"s/correcting/changing" could imply that you're changing my words. If
you want to express your own opinion (which is perfectly valid even
though I disagree with it), please use your own words.

Perhaps "preference " would be more accurate than "opinion". But
having multiple words with distinct meanings makes for clearer
communication.

>but I'll certainly make an effort to use the terms
>consistently myself, and I encourage others to do so as well.

>
I do see your point and, in general, I even agree with it. But this,
to me, seems to be taking consistency a little too far. Emerson and
all that.

I don't see it as a *foolish* consistency. I see it as using distinct
words for distinct (but similar) things.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

**Richard Tobin** · Oct 29 '08, 07:15 PM

Re: Sequence Point before actual function call

In article <87y7071jyi.fsf @nonospaz.fatph il.org>,
Phil Carmody <thefatphil_dem unged@yahoo.co. ukwrote:

>In my time teaching, I came to associate the usage of expressions
>like "i++ returns the original value of i" with my less capable
>students. The ones who understood more about what goes into the
>syntax and semantics of computer languages, and how compilers work,
>would almost certainly never have used the term. It might be pedantry,
>but I think that avoiding the term carries greater precision, and at
>no extra cost.

That seems very odd, because it's not a universal feature of computer
lnguages that there's an distinction between syntactic expressions
and function calls. What is it about the "semantics of computer
languages" and "how compilers work" that makes it resonable to say
the Lisp's (x + y) returns the sum of x and y, but not that C's
x+y does the same? The distinction can only rest on syntax.

-- Richard
--
Please remember to mention me / in tapes you leave behind.

Sequence Point before actual function call

Sequence Point before actual function call

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment