From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23791 invoked by alias); 4 Apr 2002 00:11:16 -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 23784 invoked from network); 4 Apr 2002 00:11:15 -0000 Received: from unknown (HELO mail-out2.apple.com) (17.254.0.51) by sources.redhat.com with SMTP; 4 Apr 2002 00:11:15 -0000 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g340BEs12007 for ; Wed, 3 Apr 2002 16:11:14 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 3 Apr 2002 16:10:49 -0800 Received: from inghji (inghji.apple.com [17.202.40.220]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id g340BAv28514; Wed, 3 Apr 2002 16:11:14 -0800 (PST) Date: Wed, 03 Apr 2002 16:11: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: gdb-patches@sources.redhat.com To: Jim Blandy From: Jim Ingham In-Reply-To: Message-Id: <775EF184-4760-11D6-A9CC-000393540DDC@apple.com> Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00084.txt.bz2 Jim, For incomplete types, TYPE_LENGTH does indeed return 0. If it is an incomplete type, I don't think you should treat the size as 0, since that is CERTAINLY not what the user expected. If you are going to handle it specially, then you should return an error in this case, saying something like "Can't do pointer arithmetic on incomplete types, try casting it as (void *)." The way the problem came up is that the Toolbox folks here use lots of intentionally incomplete structures to mark tokens that are hiding real structures behind the curtains. But they know the secret handshakes, so they know where things are around the pointers to fake structs, and use this kind of pointer arithmetic to poke around. So treating the addition as void * is what they expect, and an error would probably mildly tick them off. OTOH, you can always get around this by casting the pointer, either to void * or to what it is... I am pretty sure their use is just shorthand. 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... Jim On Wednesday, April 3, 2002, at 02:52 PM, Jim Blandy wrote: > > (Thanks for making value_add and value_sub consistent!) > > If I use an incomplete type in my program --- say, by making a > definition like this: > > struct foo *x; > > where there is no definition for `struct foo' in scope --- does GDB > set TYPE_LENGTH (TYPE_TARGET_TYPE (p)) to zero, where `p' is the type > of x? > > See, that code in value_add (and now in value_sub) is supposed to > handle void *; as an extension, GCC allows arithmetic on void * > values, treating sizeof (void) as one. This makes sense for void * > values, since they're often used as pointers to raw memory. > > However, for things like incomplete struct types, treating the size as > one is completely bogus. That's surely not the behavior the user > would expect; they may not even realize that the type is incomplete. > > If GDB really does set the length of an incomplete struct type to > zero, then that code should really read something like: > > if (sz == 0 && TYPE_CODE (TYPE_TARGET_TYPE (type1)) == TYPE_CODE_VOID) > sz = 1; > > Can you tell me more about the context in which you noticed this > problem? > -- Jim Ingham jingham@apple.com Developer Tools - gdb Apple Computer