From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29050 invoked by alias); 19 Oct 2005 09:51:30 -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 28999 invoked by uid 22791); 19 Oct 2005 09:51:27 -0000 Received: from fra-del-02.spheriq.net (HELO fra-del-02.spheriq.net) (195.46.51.98) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 19 Oct 2005 09:51:27 +0000 Received: from fra-out-01.spheriq.net (fra-out-01.spheriq.net [195.46.51.129]) by fra-del-02.spheriq.net with ESMTP id j9J9pNf3012295 for ; Wed, 19 Oct 2005 09:51:23 GMT Received: from fra-cus-01.spheriq.net (fra-cus-01.spheriq.net [195.46.51.37]) by fra-out-01.spheriq.net with ESMTP id j9J9pL7T019928 for ; Wed, 19 Oct 2005 09:51:22 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by fra-cus-01.spheriq.net with ESMTP id j9J9pHlw007190 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 19 Oct 2005 09:51:20 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id C7E0FDA4B; Wed, 19 Oct 2005 09:50:24 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id 82D1A472A9; Wed, 19 Oct 2005 09:53:10 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 1B96575994; Wed, 19 Oct 2005 09:53:10 +0000 (UTC) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 65869472CA; Wed, 19 Oct 2005 09:53:07 +0000 (GMT) Received: from [164.129.15.13] (terrorhawk.bri.st.com [164.129.15.13]) by mail1.bri.st.com (MOS 3.5.8-GR) with ESMTP id CDD00957 (AUTH "andrew stubbs"); Wed, 19 Oct 2005 10:50:19 +0100 (BST) Message-ID: <43561685.3010300@st.com> Date: Wed, 19 Oct 2005 09:51:00 -0000 From: Andrew STUBBS User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 To: Eli Zaretskii Cc: gdb-patches@sources.redhat.com Subject: Re: PATCH: Problem union comparision in TUI References: <4353BA69.1030401@st.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-O-Spoofed: Not Scanned X-O-General-Status: No X-O-Spam1-Status: Not Scanned X-O-Spam2-Status: Not Scanned X-O-URL-Status: Not Scanned X-O-Virus1-Status: No X-O-Virus2-Status: Not Scanned X-O-Virus3-Status: No X-O-Virus4-Status: No X-O-Virus5-Status: Not Scanned X-O-Image-Status: Not Scanned X-O-Attach-Status: Not Scanned X-SpheriQ-Ver: 2.3.0 X-SW-Source: 2005-10/txt/msg00157.txt.bz2 Eli Zaretskii wrote: > IMHO, a better way of fixing this would be to change > tui_line_or_address to be a struct as follows: > > /* Structure describing source line or line address */ > struct tui_line_or_address > { > unsigned char what > union { > int line_no; > CORE_ADDR addr; > } u; > }; > > and then fill the `what' member as appropriate and use the right part > of the union in the comparison. > Yes, that might be true, but that would be a much larger change and I would be much less confident of having done it right, plus it will add some complexity. A quick grep says there are 51 references to 'line_or_addr', but there are about 15 places other names are declared for this thing so all the uses might take a little more tracking down. I suppose changing the name of the members and seeing what breaks will be the best way. Is there any reason for using a union here? It's not like one value is float and the other int - both are ints and the fact that you can't tell which you are using shows nobody actually uses the distinction (unless I have missed something). The union doesn't save any space, nor does it make the code any more efficient. We could just use: CORE_ADDR line_or_address; and leave it at that. Anyway, I am happy to modify the patch to whatever is suggested. Thanks Andrew Stubbs