Question for ISO C standards gurus

Question for ISO C standards gurus

[law]

Given something like this:


execfuncdef(Estate state, int do_exec)
{
    Shfunc shf;
    char *s;
    int signum, nprg, sbeg, nstrs, npats, len, plen, i, htok = 0;
    Wordcode beg = state->pc, end;
    Eprog prog;
    Patprog *pp;
    LinkList names;
    end = beg + ((state->pc[-1]) >> 5);
    if (!(names = ecgetlist(state, *state->pc++, 2, &htok))) {
      state->pc = end;
      return 0;
    }
}


Does the ISO standard say anything about when the side effect of incrementing
state->pc takes effect?  Or is it implementation dependent?  Of particular
interest is whether or not the increment occurs before the call or after
the call.

jeff

RE: Question for ISO C standards gurus

[Dave Korn]

> -----Original Message-----
> From: gcc-owner On Behalf Of law@redhat.com
> Sent: 25 March 2004 18:03

> Given something like this:
> 
> 
> execfuncdef(Estate state, int do_exec)
> {
>     Shfunc shf;
>     char *s;
>     int signum, nprg, sbeg, nstrs, npats, len, plen, i, htok = 0;
>     Wordcode beg = state->pc, end;
>     Eprog prog;
>     Patprog *pp;
>     LinkList names;
>     end = beg + ((state->pc[-1]) >> 5);
>     if (!(names = ecgetlist(state, *state->pc++, 2, &htok))) {
>       state->pc = end;
>       return 0;
>     }
> }
> 
> 
> Does the ISO standard say anything about when the side effect 
> of incrementing
> state->pc takes effect?  Or is it implementation dependent?  Of 
> state->particular
> interest is whether or not the increment occurs before the 
> call or after the call.
> 
> jeff
 
  Isn't there a sequence point in between evaluating function args and
actually doing the function call that will force the side-effects to have
been applied?

http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=%22sequence+point%22+
function+call+evaluate+arguments

takes me to

http://www.langer.camelot.de/Articles/VSJ/SequencePoints/SequencePoints.html


which certainly suggests so:

"Here is the complete list of all sequence points in C++: 

at the end of a full expression 

after the evaluation of all function arguments in a function call and before
execution of any expressions in the function body 

after copying of a returned value and before execution of any expressions
outside the function 

after evaluation of the first expression in a&&b,  a||b,  a?b:c,  or  a,b 

after the initialization of each base and member in the constructor
initialization list "



    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....
 

Re: Question for ISO C standards gurus

[Paul Jarc]

law@redhat.com wrote:
>     if (!(names = ecgetlist(state, *state->pc++, 2, &htok))) {
...
> Of particular interest is whether or not the increment occurs before
> the call or after the call.

n869, 6.5.2.2p10:
# The order of evaluation of the function designator, the actual
# arguments, and subexpressions within the actual arguments is
# unspecified, but there is a sequence point before the actual call.

So the side effect would take place before the sequence point, and
thus before the call.  n869 was the latest public draft of C99; I
don't have a copy of the final standard.  It's possible that this
might have changed.


paul

Re: Question for ISO C standards gurus

[Dale Johannesen]

On Mar 25, 2004, at 10:12 AM, Paul Jarc wrote:

> law@redhat.com wrote:
>>     if (!(names = ecgetlist(state, *state->pc++, 2, &htok))) {
> ...
>> Of particular interest is whether or not the increment occurs before
>> the call or after the call.
>
> n869, 6.5.2.2p10:
> # The order of evaluation of the function designator, the actual
> # arguments, and subexpressions within the actual arguments is
> # unspecified, but there is a sequence point before the actual call.
>
> So the side effect would take place before the sequence point, and
> thus before the call.  n869 was the latest public draft of C99; I
> don't have a copy of the final standard.  It's possible that this
> might have changed.

The final standard says the same, as does C89.

RE: Question for ISO C standards gurus

[Diego Novillo]

On Thu, 2004-03-25 at 13:08, Dave Korn wrote:

> "Here is the complete list of all sequence points in C++: 
> 
> at the end of a full expression 
> 
> after the evaluation of all function arguments in a function call and before
> execution of any expressions in the function body 
> 
> after copying of a returned value and before execution of any expressions
> outside the function 
> 
> after evaluation of the first expression in a&&b,  a||b,  a?b:c,  or  a,b 
> 
> after the initialization of each base and member in the constructor
> initialization list "
> 
So, the program below should print 5?  It certainly doesn't with gcc 3.2
nor mainline:

int foo (int x)
{
  return x;
}

main ()
{
  int *p;
  int a[2];
  a[0] = 4;
  a[1] = 5;
  p = a;
  printf ("%d\n", foo (*p++));
}

It will print 5 if I use pre-increment on 'p', which is what I would've
expected (I'm no language lawyer, though).


Diego.

Re: Question for ISO C standards gurus

[Ian Lance Taylor]

Diego Novillo <dnovillo@redhat.com> writes:

> On Thu, 2004-03-25 at 13:08, Dave Korn wrote:
> 
> > "Here is the complete list of all sequence points in C++: 
> > 
> > at the end of a full expression 
> > 
> > after the evaluation of all function arguments in a function call and before
> > execution of any expressions in the function body 
> > 
> > after copying of a returned value and before execution of any expressions
> > outside the function 
> > 
> > after evaluation of the first expression in a&&b,  a||b,  a?b:c,  or  a,b 
> > 
> > after the initialization of each base and member in the constructor
> > initialization list "
> > 
> So, the program below should print 5?  It certainly doesn't with gcc 3.2
> nor mainline:
> 
> int foo (int x)
> {
>   return x;
> }
> 
> main ()
> {
>   int *p;
>   int a[2];
>   a[0] = 4;
>   a[1] = 5;
>   p = a;
>   printf ("%d\n", foo (*p++));
> }
> 
> It will print 5 if I use pre-increment on 'p', which is what I would've
> expected (I'm no language lawyer, though).

I can't see any reason why that would print 5.  Based on the above, p
should be incremented before the function call to foo().  But that
doesn't change the value of *p++, which means "get the value at *p,
then increment p".  The above just means that this should not happen:
    t1 = *p;
    foo (t1);
    p = p + 1;
(at least, it should not be possible to observe that that happened; in
the above program, p, as a local variable whose address is not taken,
probably could be incremented after the function call, since there is
no way for anything to detect when the increment occurred.)

Ian

Re: Question for ISO C standards gurus

[Diego Novillo]

On Fri, 2004-03-26 at 20:25, Ian Lance Taylor wrote:

> I can't see any reason why that would print 5.  Based on the above, p
> should be incremented before the function call to foo().  But that
> doesn't change the value of *p++, which means "get the value at *p,
> then increment p".  The above just means that this should not happen:
>     t1 = *p;
>     foo (t1);
>     p = p + 1;
>
Thanks.  Now I know what the bug is, then.


Diego.

Re: Question for ISO C standards gurus

[law]

In message <1080348071.4600.244.camel@localhost.localdomain>, Diego Novillo wri
tes:
 >On Thu, 2004-03-25 at 13:08, Dave Korn wrote:
 >
 >> "Here is the complete list of all sequence points in C++: 
 >> 
 >> at the end of a full expression 
 >> 
 >> after the evaluation of all function arguments in a function call and befor
 >e
 >> execution of any expressions in the function body 
 >> 
 >> after copying of a returned value and before execution of any expressions
 >> outside the function 
 >> 
 >> after evaluation of the first expression in a&&b,  a||b,  a?b:c,  or  a,b 
 >> 
 >> after the initialization of each base and member in the constructor
 >> initialization list "
 >> 
 >So, the program below should print 5?  It certainly doesn't with gcc 3.2
 >nor mainline:
No, it should print 4.

First you evaluate the argument to produce the passed-in value, note this
will not reflect any post side effects.  Then you emit the post side effects.

This effectively means that when you have post side effects that you have
to compute the value for the argument into a temporary and use the temporary
in the function call.

The ordering of stuff for a call effectively looks like

prequeue fncall
prequeue arg0
prequeue arg1
prequeue arg2
...
prequeue argn

temp0 = arg0
temp1 = arg1
temp2 = arg2
...
tempn = argn

postqueue arg0
postqueue arg1
postqueue arg2
...
postqueue argn

fncall (temp0, temp1, temp2, ... tempn)

poster fncall

Clearly for cases where there are no postqueues for a particular argument
you need not create a temporary and instead can use the evaluated argument
directly in the call.

Jeff

RE: Question for ISO C standards gurus

[Dave Korn]

> -----Original Message-----
> From: gcc-owner Behalf Of Ian Lance Taylor
> Sent: 27 March 2004 01:26

> Diego Novillo writes:
> 
> > On Thu, 2004-03-25 at 13:08, Dave Korn wrote:
> > 
> > > "Here is the complete list of all sequence points in C++: 
[...snip...]
> > > after the evaluation of all function arguments in a function call 
> > > and before execution of any expressions in the function body

[...snip...]
> > So, the program below should print 5?  It certainly doesn't 
> with gcc 
> > 3.2 nor mainline:
> > 
> > int foo (int x)
> > {
> >   return x;
> > }
> > 
> > main ()
> > {
> >   int *p;
> >   int a[2];
> >   a[0] = 4;
> >   a[1] = 5;
> >   p = a;
> >   printf ("%d\n", foo (*p++));
> > }
> > 
> > It will print 5 if I use pre-increment on 'p', which is what I 
> > would've expected (I'm no language lawyer, though).
> 
> I can't see any reason why that would print 5.  Based on the 
> above, p should be incremented before the function call to 
> foo().  But that doesn't change the value of *p++, which 
> means "get the value at *p, then increment p".  The above 
> just means that this should not happen:
>     t1 = *p;
>     foo (t1);
>     p = p + 1;
> (at least, it should not be possible to observe that that 
> happened; in the above program, p, as a local variable whose 
> address is not taken, probably could be incremented after the 
> function call, since there is no way for anything to detect 
> when the increment occurred.)
> 
> Ian



Indeed, that's my understanding as well.  I'd also mention that if foo was a
nested function and had access from its inner scope to the value of *p in
the enclosing function, it should be 5 at the time control flow was in foo.



    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....