There is a buffer overflow error in GCJ while reading in large FP literals, as
shown by Jacks testcase 3.10.2-round-6 (and others). On my machine, this
manifests itself only when "parse.y" or "lex.c" is recompiled at -O0 after a
full bootstrap, like so:
cd $GCC_SRC_DIR/gcc/java
touch parse.y
cd $BUILD_DIR
make BOOT_CFLAGS='-O0 -g3' bubblestrap
Compile the attached testcase before and after this. In my case, it gives
the expected "Floating point literal too large error" only in the former
case.
The array "literal_token" in do_java_lex() in lex.c is 256 characters
long, but the subsequent code merrily overwrites long literals past this
limit. A silly patch to overcome this particular error is:
Index: lex.c
===================================================================
--- lex.c 2005-06-18 17:04:00.000000000 +0530
+++ lex.c 2005-06-18 17:06:14.000000000 +0530
@@ -965,7 +965,7 @@ do_java_lex (YYSTYPE *java_lval)
int parts[TOTAL_PARTS];
HOST_WIDE_INT high, low;
/* End borrowed section. */
- char literal_token [256];
+ char literal_token [512];
int literal_index = 0, radix = 10, long_suffix = 0, overflow = 0, bytes;
int found_hex_digits = 0, found_non_octal_digits = -1;
int i;
But of course this won't do. We need to have a better fix for
this issue. I'm filing this bug so that we don't lose track of
this issue.
--
Summary: Buffer overflow in the lexical analyser while reading FP
literals
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmathew at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22113
