From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28907 invoked by alias); 14 Aug 2007 04:27:16 -0000 Received: (qmail 28858 invoked by uid 22791); 14 Aug 2007 04:27:15 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 14 Aug 2007 04:27:12 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 1C8B12AA1DE; Tue, 14 Aug 2007 00:27:11 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HhyZ5zjiJtlP; Tue, 14 Aug 2007 00:27:11 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id B1EF62AA1DB; Tue, 14 Aug 2007 00:27:10 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 750E1E7B54; Mon, 13 Aug 2007 21:30:53 -0700 (PDT) Date: Tue, 14 Aug 2007 04:27:00 -0000 From: Joel Brobecker To: msnyder@sonic.net Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] ada-lang, possible_user_operator_p, null pointer Message-ID: <20070814043053.GB11498@adacore.com> References: <19577.12.7.175.2.1186864998.squirrel@webmail.sonic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19577.12.7.175.2.1186864998.squirrel@webmail.sonic.net> User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-08/txt/msg00278.txt.bz2 > 2007-08-11 Michael Snyder > > * ada-lang.c (possible_user_operator_p): Guard against NULL. This is another case where I'd prefer to have the check for a NULL type moved to the top of the function. But I'm having a tough time determining how this might actually happen. So I'd like to sit on it for a little longer before we proceed. > Also, I'm not sure what the CONCAT operator is, but is it > possible that the OR at the beginning of the same line > should be an AND? Just checking... The BINOP_CONCAT operator corresponds to the "&" binop operator, which allows us to concatenate two arrays into one. For instance, you may have some code like this: Hello : constant String := "Hello"; There : constant String := "there"; Hello_There : constant String := Hello & " " & There; In terms of the condition, it's kind of confusing, since the logic is sort of backwards as far as my brain seems to work. But I think the condition is actually correct: If you have an array on each side, then use the pre-defined operator. So if you negate this condition, if either lhs *or* rhs are not arrays, then... > Index: ada-lang.c > =================================================================== > RCS file: /cvs/src/src/gdb/ada-lang.c,v > retrieving revision 1.100 > diff -p -r1.100 ada-lang.c > *** ada-lang.c 6 Aug 2007 20:07:44 -0000 1.100 > --- ada-lang.c 11 Aug 2007 20:39:20 -0000 > *************** possible_user_operator_p (enum exp_opcod > *** 3536,3542 **** > ((TYPE_CODE (type0) != TYPE_CODE_ARRAY > && (TYPE_CODE (type0) != TYPE_CODE_PTR > || TYPE_CODE (TYPE_TARGET_TYPE (type0)) != TYPE_CODE_ARRAY)) > ! || (TYPE_CODE (type1) != TYPE_CODE_ARRAY > && (TYPE_CODE (type1) != TYPE_CODE_PTR > || (TYPE_CODE (TYPE_TARGET_TYPE (type1)) > != TYPE_CODE_ARRAY)))); > --- 3536,3542 ---- > ((TYPE_CODE (type0) != TYPE_CODE_ARRAY > && (TYPE_CODE (type0) != TYPE_CODE_PTR > || TYPE_CODE (TYPE_TARGET_TYPE (type0)) != TYPE_CODE_ARRAY)) > ! || (type1 != NULL && TYPE_CODE (type1) != TYPE_CODE_ARRAY > && (TYPE_CODE (type1) != TYPE_CODE_PTR > || (TYPE_CODE (TYPE_TARGET_TYPE (type1)) > != TYPE_CODE_ARRAY)))); -- Joel