[PATCH] java.util.StringTokenizer assumes order of parameter evaluation

Mark Wielaard mark@klomp.org
Fri Oct 25 03:49:00 GMT 2002


Hi,

On Wed, 2002-10-16 at 15:09, Andrew Haley wrote:
> Ranjit Mathew writes:
>  > Sorry guys, but I just referred to the JLS (section 15.12.4.2,
>  > "Evaluate Arguments"):
>  > 
>  > http://java.sun.com/docs/books/jls/second_edition/html/expressions.doc.html#45449
>  > 
>  > and I quote:
>  > 
>  > "The argument expressions are evaluated in order, from left to right..."
>  > 
>  > Therefore, the coder for StringTokenizer *can* assume the
>  > order of evaluation - there must be some other problem that
>  > I need to figure out.
>  > 
>  > BTW, does GCJ guarantee this order at all times? (I just saw
>  > Andrew Haley's patch for a fix for *static* method invocation,
>  > but the StringTokenizer problem is in a member method.)
> 
> Ah, here's another version of that patch.  I won't commit it because
> it's not fully tested yet.
> [...] 
> 2002-10-15  Andrew Haley  <aph@redhat.com>
> 
> 	* parse.y (patch_invoke): Call force_evaluation_order on a static
> 	arg list.
> 	(resolve_qualified_expression_name): Call force_evaluation_order
> 	on a arg list that is part of a Qualified Expression Name.
> 
> 	* lang.c (dump_compound_expr): New.
> 	(java_dump_tree): New.

I saw that you applied this patch so I tried a new gcj checkout on the
attached testcase from Casey Marshall that he found when trying to
analyse why compiling GNU Crypto with gcj -O2 produced incorrect
results.

GNU Crypto already contains a workaround for this issue but the attached
program does not produce correct results (with or without! -O2).

It seems that the arguments to the methods get mixed up in the following
statement:

result[j++] = (byte)(
    (fromDigit(s.charAt(i++)) << 4) | fromDigit(s.charAt(i++)));

Compiling with gcj -C produces bytecode that runs correctly with gij.

Correct output should be:

0123456789ABCDEF
0123456789ABCDEF
0123456789ABCDEF

But is:

0123456789ABCDEF
0123456789ABCDEF
1032547698BADCFE

Cheers,

Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: utilTest.java
Type: text/x-java
Size: 1785 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java-patches/attachments/20021025/02501834/attachment.bin>


More information about the Java-patches mailing list