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

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

[Daniel Jacobowitz]

I don't know if Java allows the implicit 0x123456789 -> 0x123456789L
conversion that we all know and love in C, but it certainly behooves us to
act that way on the command line.  Per, does this patch look OK?

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

2002-02-11  Daniel Jacobowitz  <drow@mvista.com>

	Fix PR gdb/265
	* jv-exp.y (parse_number): Handle 64-bit integers.

Index: jv-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/jv-exp.y,v
retrieving revision 1.3
diff -u -p -r1.3 jv-exp.y
--- jv-exp.y	2001/03/06 08:21:09	1.3
+++ jv-exp.y	2002/02/11 05:32:18
@@ -764,13 +764,13 @@ parse_number (p, len, parsed_float, puti
       }
 
   c = p[len-1];
+  /* A paranoid calculation of (1<<64)-1. */
   limit = (ULONGEST)0xffffffff;
+  limit = ((limit << 16) << 16) | limit;
   if (c == 'l' || c == 'L')
     {
       type = java_long_type;
       len--;
-      /* A paranoid calculation of (1<<64)-1. */
-      limit = ((limit << 16) << 16) | limit;
     }
   else
     {
@@ -797,9 +797,13 @@ parse_number (p, len, parsed_float, puti
       n += c;
 	}
 
-   putithere->typed_val_int.val = n;
-   putithere->typed_val_int.type = type;
-   return INTEGER_LITERAL;
+  if (type == java_int_type && n > (ULONGEST)0xffffffff)
+    type = java_long_type;
+
+  putithere->typed_val_int.val = n;
+  putithere->typed_val_int.type = type;
+
+  return INTEGER_LITERAL;
 }
 
 struct token

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

[Tom Tromey]

>>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:

Daniel> I don't know if Java allows the implicit 0x123456789 ->
Daniel> 0x123456789L conversion that we all know and love in C

Nope.  In Java an integer constant which is too big for its type is an
error.

Daniel> but it certainly behooves us to act that way on the command
Daniel> line.

If/when we implement method invocation, won't this mean we could
silently call the wrong overloaded method?

Tom

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

[Daniel Jacobowitz]

On Mon, Feb 11, 2002 at 11:47:20AM -0700, Tom Tromey wrote:
> >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> 
> Daniel> I don't know if Java allows the implicit 0x123456789 ->
> Daniel> 0x123456789L conversion that we all know and love in C
> 
> Nope.  In Java an integer constant which is too big for its type is an
> error.
> 
> Daniel> but it certainly behooves us to act that way on the command
> Daniel> line.
> 
> If/when we implement method invocation, won't this mean we could
> silently call the wrong overloaded method?

Only if the user specifies a constant too large.  Normal constants are
still maintained as java_int_type.  But if that becomes an issue we can
add a flag to parse_number later to conditionalize this, and modify the
parser appropriately.  x/i (for instance) should always accept 64-bit
constants.

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

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

[Daniel Jacobowitz]

On Mon, Feb 11, 2002 at 12:38:18AM -0500, Daniel Jacobowitz wrote:
> I don't know if Java allows the implicit 0x123456789 -> 0x123456789L
> conversion that we all know and love in C, but it certainly behooves us to
> act that way on the command line.  Per, does this patch look OK?

Per never answered me, and I satisfied Tom's objections.  I'm committing
this as reasonably obvious, in my quest to shrink the number of "I
should look at this" PRs in my mailbox.

> 
> -- 
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer
> 
> 2002-02-11  Daniel Jacobowitz  <drow@mvista.com>
> 
> 	Fix PR gdb/265
> 	* jv-exp.y (parse_number): Handle 64-bit integers.
> 
> Index: jv-exp.y
> ===================================================================
> RCS file: /cvs/src/src/gdb/jv-exp.y,v
> retrieving revision 1.3
> diff -u -p -r1.3 jv-exp.y
> --- jv-exp.y	2001/03/06 08:21:09	1.3
> +++ jv-exp.y	2002/02/11 05:32:18
> @@ -764,13 +764,13 @@ parse_number (p, len, parsed_float, puti
>        }
>  
>    c = p[len-1];
> +  /* A paranoid calculation of (1<<64)-1. */
>    limit = (ULONGEST)0xffffffff;
> +  limit = ((limit << 16) << 16) | limit;
>    if (c == 'l' || c == 'L')
>      {
>        type = java_long_type;
>        len--;
> -      /* A paranoid calculation of (1<<64)-1. */
> -      limit = ((limit << 16) << 16) | limit;
>      }
>    else
>      {
> @@ -797,9 +797,13 @@ parse_number (p, len, parsed_float, puti
>        n += c;
>  	}
>  
> -   putithere->typed_val_int.val = n;
> -   putithere->typed_val_int.type = type;
> -   return INTEGER_LITERAL;
> +  if (type == java_int_type && n > (ULONGEST)0xffffffff)
> +    type = java_long_type;
> +
> +  putithere->typed_val_int.val = n;
> +  putithere->typed_val_int.type = type;
> +
> +  return INTEGER_LITERAL;
>  }
>  
>  struct token
> 

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

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

[Per Bothner]

Daniel Jacobowitz wrote:
> On Mon, Feb 11, 2002 at 12:38:18AM -0500, Daniel Jacobowitz wrote:
> 
>>I don't know if Java allows the implicit 0x123456789 -> 0x123456789L
>>conversion that we all know and love in C,

It doesn't. From the Java Languages Specification 2nd ed 3.10.1:

   A compile-time error occurs if a decimal literal of type int is larger
   than 2147483648 (2^31), or if the literal 2147483648 appears anywhere
   other than as the operand of the unary - operator, or if a hexadecimal
   or octal int literal does not fit in 32 bits.

 > but it certainly behooves us to act that way on the command line.

I don't see that.  I think the current error is reasonable, but perhaps
changing it to a warning would be better.  However, silently changing
the type may change which overloaded methods gets chosen, so it's a bad
idea.

> Per never answered me, 

Sorry.  I guess I didn't notice the question to me.

 > I'm committing this as reasonably obvious,

Please don't - it's wrong.

>>+  if (type == java_int_type && n > (ULONGEST)0xffffffff)
>>+    type = java_long_type;

One might argue that if the radix is 10, perhaps it should be
n > (ULONGEST)0x80000000 (given that Java doesn't have unsigned types).
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

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

[Daniel Jacobowitz]

On Wed, Feb 20, 2002 at 03:04:55PM -0800, Per Bothner wrote:
> Daniel Jacobowitz wrote:
> >On Mon, Feb 11, 2002 at 12:38:18AM -0500, Daniel Jacobowitz wrote:
> >
> >>I don't know if Java allows the implicit 0x123456789 -> 0x123456789L
> >>conversion that we all know and love in C,
> 
> It doesn't. From the Java Languages Specification 2nd ed 3.10.1:
> 
>   A compile-time error occurs if a decimal literal of type int is larger
>   than 2147483648 (2^31), or if the literal 2147483648 appears anywhere
>   other than as the operand of the unary - operator, or if a hexadecimal
>   or octal int literal does not fit in 32 bits.
> 
> > but it certainly behooves us to act that way on the command line.
> 
> I don't see that.  I think the current error is reasonable, but perhaps
> changing it to a warning would be better.  However, silently changing
> the type may change which overloaded methods gets chosen, so it's a bad
> idea.

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.

Yes, it means for
(gdb) call foo.bar(0x123456789)
we will call the version expecting a long.  But at the same time we
accept things like

(gdb) ptype baz
type = struct {
  int x;
} *
(gdb) print baz.x

Which is obviously bogus C, but valid "GDB expression evaluator in
C-like mode" syntax.  I think this is a valid extension of existing
practice.

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.

> >Per never answered me, 
> 
> Sorry.  I guess I didn't notice the question to me.

Sorry for acting prematurely, then.  I should have nagged first.

> > I'm committing this as reasonably obvious,
> 
> Please don't - it's wrong.
> 
> >>+  if (type == java_int_type && n > (ULONGEST)0xffffffff)
> >>+    type = java_long_type;
> 
> One might argue that if the radix is 10, perhaps it should be
> n > (ULONGEST)0x80000000 (given that Java doesn't have unsigned types).

The problem is that this is used for all expressions, and holding all
expressions to strict Java conformance does not seem right to me at
all.

Thoughts?

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

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

[Per Bothner]

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.

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.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

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

[Daniel Jacobowitz]

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

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

[Per Bothner]

Daniel Jacobowitz wrote:
> This look OK?  Note the comment.

Perfect.

> -  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;
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

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

[Daniel Jacobowitz]

On Wed, Feb 20, 2002 at 06:12:13PM -0800, Per Bothner wrote:
> Daniel Jacobowitz wrote:
> >This look OK?  Note the comment.
> 
> Perfect.

Committed.  All done with Java for the moment, I think - I'll be back
to it once I have some time for namespaces.

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