Re: Fix PR gdb/265, 64-bit pointers in Java

[Daniel Jacobowitz <drow@mvista.com>]

On Wed, Feb 20, 2002 at 05:30:40PM -0800, Per Bothner wrote:
> Daniel Jacobowitz wrote:
> >Well, it does not silently change the type for conforming input;
> >integers will still be marked as integers.  The patch allows us to accept
> >things like:
> >(gdb) x/i 0x123456789
> >
> >which really ought to work.
> 
> I'm not 100% convinced, but it's at least reasonable.
> 
> >If you disagree with me on that, which you certainly can :), then I
> >would prefer to have a flag for parse_number saying it created an
> >implicit long and cause errors if the expression being evaluated is a
> >method call, etc.  I'm not convinced that's worth the trouble.
> 
> An idea: If it overflows, set the type to builtin_type_uint64, or some
> similar type, but don't set it to java_type_long.  That way we still
> get x/i 0x123456789 to do the expected, but we can (if we wanted to)
> catch incorrectly passing 0x123456789 to a Java method.

I like it.

> This is similar to how G++ treets jint (__java_int), as a different
> integer type than int, so it can can programs that try to incorrectly
> pass an 'int' to a Java method.
> 
> If you change it to:
> 
>   if (type == java_int_type && n > (ULONGEST)0x80000000)
>      type = builtin_type_uint64;
> 
> then that would satisfy me.

This look OK?  Note the comment.

Index: jv-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/jv-exp.y,v
retrieving revision 1.4
diff -u -p -r1.4 jv-exp.y
--- jv-exp.y	2002/02/20 22:41:52	1.4
+++ jv-exp.y	2002/02/21 02:04:19
@@ -797,8 +797,13 @@ parse_number (p, len, parsed_float, puti
       n += c;
 	}
 
-  if (type == java_int_type && n > (ULONGEST)0xffffffff)
-    type = java_long_type;
+  /* If the type is bigger than a 32-bit signed integer can be, implicitly
+     promote to long.  Java does not do this, so mark it as builtin_type_uint64
+     rather than java_long_type.  0x80000000 will become -0x80000000 instead
+     of 0x80000000L, because we don't know the sign at this point.
+  */
+  if (type == java_int_type && n > (ULONGEST)0x80000000)
+    type = builtin_type_uint64;
 
   putithere->typed_val_int.val = n;
   putithere->typed_val_int.type = type;


-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer