This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: Fix PR gdb/265, 64-bit pointers in Java
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