From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8323 invoked by alias); 4 Apr 2002 21:46:11 -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 8304 invoked from network); 4 Apr 2002 21:46:04 -0000 Received: from unknown (HELO mail-out2.apple.com) (17.254.0.51) by sources.redhat.com with SMTP; 4 Apr 2002 21:46:04 -0000 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g34Lk4s29315 for ; Thu, 4 Apr 2002 13:46:04 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 4 Apr 2002 13:46:03 -0800 Received: from inghji (inghji.apple.com [17.202.40.220]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g34Lk3i03438; Thu, 4 Apr 2002 13:46:03 -0800 (PST) Date: Thu, 04 Apr 2002 13:46:00 -0000 Subject: Re: Trivial fix in value_sub Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: Jim Blandy , gdb-patches@sources.redhat.com To: Daniel Jacobowitz From: Jim Ingham In-Reply-To: <20020403231150.A9816@nevyn.them.org> Message-Id: <5BEA75A4-4815-11D6-86BE-000393540DDC@apple.com> Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00131.txt.bz2 Okay, so to be consistent, I throw errors in both value_add & value_sub. How about this: Index: valarith.c =================================================================== RCS file: /cvs/src/src/gdb/valarith.c,v retrieving revision 1.14 diff -c -w -p -r1.14 valarith.c *** valarith.c 2002/03/27 21:35:35 1.14 --- valarith.c 2002/04/04 21:39:58 *************** value_add (struct value *arg1, struct va *** 48,55 **** { struct value *valint; struct value *valptr; ! register int len; struct type *type1, *type2, *valptrtype; COERCE_NUMBER (arg1); COERCE_NUMBER (arg2); --- 48,56 ---- { struct value *valint; struct value *valptr; ! register int sz; struct type *type1, *type2, *valptrtype; + struct type *valtargettype; COERCE_NUMBER (arg1); COERCE_NUMBER (arg2); *************** value_add (struct value *arg1, struct va *** 77,88 **** valint = arg1; valptrtype = type2; } ! len = TYPE_LENGTH (check_typedef (TYPE_TARGET_TYPE (valptrtype))); ! if (len == 0) ! len = 1; /* For (void *) */ retval = value_from_pointer (valptrtype, value_as_address (valptr) ! + (len * value_as_long (valint))); VALUE_BFD_SECTION (retval) = VALUE_BFD_SECTION (valptr); return retval; } --- 78,109 ---- valint = arg1; valptrtype = type2; } ! ! valtargettype = check_typedef (TYPE_TARGET_TYPE (valptrtype)); ! sz = TYPE_LENGTH (valtargettype); ! if (sz == 0) ! { ! if (TYPE_CODE (type1) == TYPE_CODE_VOID) ! sz = 1; ! else ! { ! char *name; ! ! name = TYPE_NAME (valtargettype); ! if (name == NULL) ! name = TYPE_TAG_NAME (valtargettype); ! if (name == NULL) ! error ("Cannot perform pointer addition on incomplete types, " ! "try casting to a known type, or void *."); ! else ! error ("Cannot perform pointer addition on incomplete type \"%s\", " ! "try casting to a known type, or void *.", name); ! } ! } ! retval = value_from_pointer (valptrtype, value_as_address (valptr) ! + (sz * value_as_long (valint))); VALUE_BFD_SECTION (retval) = VALUE_BFD_SECTION (valptr); return retval; } *************** value_sub (struct value *arg1, struct va *** 104,110 **** if (TYPE_CODE (type2) == TYPE_CODE_INT) { /* pointer - integer. */ ! LONGEST sz = TYPE_LENGTH (check_typedef (TYPE_TARGET_TYPE (type1))); return value_from_pointer (type1, (value_as_address (arg1) - (sz * value_as_long (arg2)))); --- 125,156 ---- if (TYPE_CODE (type2) == TYPE_CODE_INT) { /* pointer - integer. */ ! struct type *type1target = check_typedef (TYPE_TARGET_TYPE (type1)); ! LONGEST sz = TYPE_LENGTH (type1target); ! /* This is the way value_add does it. Is this right, because ! it means you have a different result depending on whether you ! have an incomplete type or not... */ ! ! if (sz == 0) ! { ! if (TYPE_CODE (type1) == TYPE_CODE_VOID) ! sz = 1; ! else ! { ! char *name; ! ! name = TYPE_NAME (type1target); ! if (name == NULL) ! name = TYPE_TAG_NAME (type1target); ! if (name == NULL) ! error ("Cannot perform pointer subtraction on incomplete types, " ! "try casting to a known type, or void *."); ! else ! error ("Cannot perform pointer subtraction on incomplete type \"%s\", " ! "try casting to a known type, or void *.", name); ! } ! } ! return value_from_pointer (type1, (value_as_address (arg1) - (sz * value_as_long (arg2)))); Jim P.S. I have long ago given up being amazed at all the egregiously heinous uses to which people will put debuggers... To quote my revered father: "If I were to shake my head and say "Oh, my god" every time I see something like this, I would spend so much time with my head & mouth in motion people would think I had acquired some form of ecclesiastical palsy..." Jim On Wednesday, April 3, 2002, at 08:11 PM, Daniel Jacobowitz wrote: > On Wed, Apr 03, 2002 at 10:54:57PM -0500, Jim Blandy wrote: >> >> Jim Ingham writes: >>> So... I don't think you should keep the size at 0. This seems like >>> gdb is just silently ignoring the " - x" part of what they typed, and >>> you should always be explicit about what you have done. But if you >>> think an error is more appropriate, I am fine with that... >> >> Oh, no, I didn't mean to suggest that zero was the right size to use; >> I agree with you completely that that would be pretty confusing. >> >> Your story is pretty amazing --- I would never have guessed that >> people actually *use* the sizeof (struct incomplete) == 1 behavior! I >> think it is much more common for people to be unaware that the type is >> incomplete; if this hunch is correct, then the behavior your toolbox >> folks love will be very confusing. I think an error for arithmetic on >> any incomplete type other than (void *) is the right thing. > > FWIW, I agree. If we don't know what the size is, we should say so; > having the behavior change based on whether a version of the > implementation (which might have debug symbols) is loaded would be > baffling. > > -- > Daniel Jacobowitz Carnegie Mellon University > MontaVista Software Debian GNU/Linux Developer > -- Jim Ingham jingham@apple.com Developer Tools - gdb Apple Computer