Date: Fri, 11 Oct 1996 15:06:45 -0700 From: Julian Elischer <julian@whistle.com> To: Philippe Charnier <charnier@xp11.frmug.org> Cc: current@FreeBSD.org Subject: Re: gcc's bug. please comment Message-ID: <325EC4F5.167EB0E7@whistle.com> References: <199610111905.VAA01615@xp11.frmug.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Philippe Charnier wrote:
>
> Hello,
>
> A friend found a bug in gcc-2.7.2.1. The following program fails on
> i386 architecture (both FreeBSD and solaris-x86) and works as expected
> on sparc (both sunos and solaris2.5.1) and on hp (hp-ux9.07). As I'm
> not on the gcc-bug list, please comment before I report the bug. This
> afternoon I sent a bug report to Sun but it was before trying on
> FreeBSD.
>
> The output should be `1 2' but it is `2 1' on i386 computers.
> Here is the code:
This is not a bug.
the C standard specifically does not define the order of evaluation in
arguments to a function.
for eas of programming, they are usually eveluated from right to left,
(giving 2 1)
but sometimes they are evaluated left to right.
arguments to a function are NOT THE SAME as a coma separated list
of statements, which are DEFINED
to evaluate from left to right.
Thus is is not goo dC to do operations on function arguments that have
side-effects as the order of evaluation can vary.
> fic=fopen("mypb2.csv","r");
> fscanf(fic, "%d;%d", &a[1][i++], &a[1][i++]);
this will assign a[1][1] before filling out a[1][0]
The reasoning was that by the time this became a noticed problem
there were already too many machines doing it each way.
julian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?325EC4F5.167EB0E7>