From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9331 invoked by alias); 21 Feb 2002 01:30:09 -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 9138 invoked from network); 21 Feb 2002 01:30:00 -0000 Received: from unknown (HELO bothner.com) (216.102.199.253) by sources.redhat.com with SMTP; 21 Feb 2002 01:30:00 -0000 Received: from bothner.com (eureka.bothner.com [192.168.1.9]) by bothner.com (8.11.6/8.11.6) with ESMTP id g1L1YOp02891; Wed, 20 Feb 2002 17:34:24 -0800 Message-ID: <3C744DC0.1090902@bothner.com> Date: Wed, 20 Feb 2002 17:30:00 -0000 From: Per Bothner User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8+) Gecko/20020215 X-Accept-Language: en-us MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb-patches@sources.redhat.com Subject: Re: Fix PR gdb/265, 64-bit pointers in Java References: <20020211003818.A26546@nevyn.them.org> <20020220174154.A29999@nevyn.them.org> <3C742B97.2060609@bothner.com> <20020220184414.A7963@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-02/txt/msg00578.txt.bz2 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/