From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-20205-listarch-gdb-patches=sources.redhat.com@sources.redhat.com>
Received: (qmail 3953 invoked by alias); 18 Nov 2002 17:52:07 -0000
Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-patches-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sources.redhat.com>
List-Help: <mailto:gdb-patches-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-patches-owner@sources.redhat.com
Received: (qmail 3942 invoked from network); 18 Nov 2002 17:52:02 -0000
Received: from unknown (HELO zenia.red-bean.com) (66.244.67.22)
  by sources.redhat.com with SMTP; 18 Nov 2002 17:52:02 -0000
Received: (from jimb@localhost)
	by zenia.red-bean.com (8.11.6/8.11.6) id gAIHZUg23729;
	Mon, 18 Nov 2002 12:35:30 -0500
To: Andrew Cagney <ac131313@redhat.com>
Cc: Klee Dienes <klee@apple.com>, Eli Zaretskii <eliz@is.elta.co.il>,
   gdb-patches@sources.redhat.com
Subject: Re: [PATCH] Compare contents when evaluating an array watchpoint
References: <C66935B8-D9BB-11D6-9563-00039396EEB8@apple.com>
	<3DB49F6C.3060106@redhat.com>
From: Jim Blandy <jimb@redhat.com>
Date: Mon, 18 Nov 2002 09:52:00 -0000
In-Reply-To: <3DB49F6C.3060106@redhat.com>
Message-ID: <vt24raen5lq.fsf@zenia.red-bean.com>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.92
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-SW-Source: 2002-11/txt/msg00461.txt.bz2


Andrew Cagney <ac131313@redhat.com> writes:
> 	int a[10];
> 	int *b;
> 	(gdb) watch a
> 	(gdb) watch b
> 	(gdb) watch *b@10
> 	(gdb) watch *a@sizeof(a)
> 
> While the existing ``watch a'' might have annoying semantics, it would
> make its behavior consistent with C.  An array is converted to a
> pointer in an expression.

Well, whether arrays are coerced to pointers depends on what you're
doing with them: see ISO C 6.3.2.  In most cases they are, but if
they're an operand to & or sizeof, then they aren't.  It's a
case-by-case thing: C chooses the most useful interpretation given the
context.  It seems consistent with C for GDB to do the same.

And in fact, GDB doesn't do "the usual unary conversions" on the final
value of an expression.  That's why when you have:

    int a[10];

then GDB does this:

    (gdb) print a
    $1 = {1, 0, 1074017445, 1075174868, 1075159808, 1073833280, 1075175900, 
      1074103810, 1073933620, 1075174868}
    (gdb) 

and not:

    (gdb) print a
    $1 = (int *) 0xbfffc100
    (gdb)

So I think Klee's patch makes GDB's behavior more consistent with
itself, more useful, and is still completely consistent with C
semantics.