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

[Daniel Jacobowitz <drow@mvista.com>]

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