From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23935 invoked by alias); 20 Feb 2002 23:44:20 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 23802 invoked from network); 20 Feb 2002 23:44:17 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 20 Feb 2002 23:44:17 -0000 Received: from drow by nevyn.them.org with local (Exim 3.34 #1 (Debian)) id 16dgPG-00027H-00; Wed, 20 Feb 2002 18:44:14 -0500 Date: Wed, 20 Feb 2002 15:44:00 -0000 From: Daniel Jacobowitz To: Per Bothner Cc: gdb-patches@sources.redhat.com Subject: Re: Fix PR gdb/265, 64-bit pointers in Java Message-ID: <20020220184414.A7963@nevyn.them.org> Mail-Followup-To: Per Bothner , gdb-patches@sources.redhat.com References: <20020211003818.A26546@nevyn.them.org> <20020220174154.A29999@nevyn.them.org> <3C742B97.2060609@bothner.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C742B97.2060609@bothner.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-02/txt/msg00572.txt.bz2 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