🚀 go-pugleaf

In article <492je7$24m@Starbase.NeoSoft.COM> claird@Starbase.NeoSoft.COM (Cameron Laird) writes:
 > >    int f (int x[]) {
 > >        int t1 = x[0];
 > >        h(t1);
 > >        return t1 + x[0];
 > >    }
...
 > >    int g (int x[]) {
 > >        int t1 = x[0];
 > >        h(t1);
 > >        return t1 + t1;
 > >    }
 > 			.
 > No.  This is a bit embarrassing, and I've been waiting
 > for someone else to explain it, but none of the numer-
 > ous follow-ups have done so.  C passes arguments by
 > value.  h() can't affect x[0] (with the exception of
 > horrible memory manipulation, which I can argue is not
 > under consideration here).

Eh?

int x[10];
void h(int y) {x[0] = y + 1;}
main() { x[0]=0; printf("%d\n", f(x)); x[0]=0; printf("%d\n", g(x)); }

C passes by value, but the definitions of f() and g() are misleading.
Actually better would be a header like "int f (int *x)" etc. (which
is identical due to the rewrite rules).  C never passes arrays, not
by value and not by reference.

 > In fact, FORTRAN looks more like a problem child in this
 > situation, because its subroutine's side-effects can bub-
 > ble back up as you have in mind.

Show me such a program and I will show you were it violates the standard.

 > I've moved follow-ups around.

And I moved the thread back again.
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland, +31205924098
home: bovenover 215, 1025 jn  amsterdam, nederland; http://www.cwi.nl/~dik/