On Sat, 30 Oct 2010 14:55:43 +0200 Hermann Peifer<address@hidden> wrote:
On 30/10/2010 13:13, Davide Brini wrote:
Back to the example, I may be wrong but the only way I see for FS ++c to
evaluate to plain 0 is that for some reason they are grouped as
FS + +c
since c is 0, "+c" is also 0, and the result of the "addition" between
FS and "+c" is 0.
FWIW, mawk shows the same behavior.
Thanks for the pointer to the FAQ. Any idea about this one:
$ gawk-stable/gawk 'BEGIN{ c++ ; print FS ++c }'
01
$ gawk-stable/gawk 'BEGIN{ c++ ; print (FS) ++c }'
2
To be honest, no. That leading 0 is puzzling, although it's clearly due to
FS being converted to numeric (using another variable does the same).
It seems the issue is definitely related to the order of evaluation in
string concatenation.
In the sceond case, mawk and gawk behave differently:
$ gawk 'BEGIN{ c++ ; print (FS) ++c }'
2
$ mawk 'BEGIN{ c++ ; print (FS) ++c }'
01
The GNU awk manual says that the order of evaluation of the expressions
used for string concatenation is undefined.
However I wasn't able to find that stated clearly in the standard, which
instead says
"In expression evaluation, where the grammar is formally ambiguous, higher
precedence operators shall be evaluated before lower precedence operators".
And in the provided table, the preincrement operator has definitely higher
precedence than string concatenation.
To quote the GNU awk manual again, "when doing concatenation, parenthesize.
Otherwise, you're never quite sure what you'll get".
And indeed putting parentheses around (++c) restores the same behavior for
both:
$ gawk 'BEGIN{ c++ ; print FS (++c) }'
2
$ mawk 'BEGIN{ c++ ; print FS (++c) }'
2
But I'd like to hear what Arnold thinks about this.