From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31271 invoked by alias); 7 Oct 2002 11:37:13 -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 31264 invoked from network); 7 Oct 2002 11:37:13 -0000 Received: from unknown (HELO cerbere.u-strasbg.fr) (130.79.112.250) by sources.redhat.com with SMTP; 7 Oct 2002 11:37:13 -0000 Received: from laocoon.ics.u-strasbg.fr (laocoon.u-strasbg.fr [130.79.112.72]) by cerbere.u-strasbg.fr (Postfix) with ESMTP id E2EF05EA for ; Mon, 7 Oct 2002 13:38:03 +0200 (CEST) Message-Id: <5.0.2.1.2.20021007132114.01e66260@ics.u-strasbg.fr> X-Sender: muller@ics.u-strasbg.fr Date: Mon, 07 Oct 2002 04:37:00 -0000 To: gdb-patches@sources.redhat.com From: Pierre Muller Subject: [RFA] Fix an error in value_change_enclosing_type Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-SW-Source: 2002-10/txt/msg00170.txt.bz2 the function value_change_enclosing_type does not set the enlclosing_type field correctly if the new_encl_type has a bigger length that the value type. Its seems quite astonishing that this has not been noticed before, but I discovered it when trying to get the fpc-abi.c code to work correctly. ChangeLog entry: 2002-10-07 Pierre Muller * values.c (value_change_enclosing_type): Set enclosing_type field correctly also for the case where more memory needs to be allocated. $ cvs diff -u -p values.c Index: values.c =================================================================== RCS file: /cvs/src/src/gdb/values.c,v retrieving revision 1.41 diff -u -p -r1.41 values.c --- values.c 18 Sep 2002 15:43:47 -0000 1.41 +++ values.c 7 Oct 2002 11:36:15 -0000 @@ -862,7 +862,9 @@ value_change_enclosing_type (struct valu struct value *prev; new_val = (struct value *) xrealloc (val, sizeof (struct value) + TYPE_LENGTH (new_encl_type)); - + + VALUE_ENCLOSING_TYPE (new_val) = new_encl_type; + /* We have to make sure this ends up in the same place in the value chain as the original copy, so it's clean-up behavior is the same. If the value has been released, this is a waste of time, but there Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99