From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Jan D." Newsgroups: gmane.emacs.devel Subject: Re: Problem report #8 FALSE Date: Mon, 10 Apr 2006 11:55:01 +0200 (CEST) Message-ID: <200604100955.k3A9t1cP028530@coolsville.localdomain> References: <200604090659.k396xI5h005539@scanner2.ics.uci.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1144662988 25119 80.91.229.2 (10 Apr 2006 09:56:28 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 10 Apr 2006 09:56:28 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 10 11:56:27 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FSt8E-0003Ba-WB for ged-emacs-devel@m.gmane.org; Mon, 10 Apr 2006 11:56:27 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FSt8E-0005b4-E0 for ged-emacs-devel@m.gmane.org; Mon, 10 Apr 2006 05:56:26 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FSt7m-0005Ti-2q for emacs-devel@gnu.org; Mon, 10 Apr 2006 05:55:58 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FSt7k-0005TA-0K for emacs-devel@gnu.org; Mon, 10 Apr 2006 05:55:57 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FSt7j-0005T7-Tm for emacs-devel@gnu.org; Mon, 10 Apr 2006 05:55:55 -0400 Original-Received: from [195.54.107.70] (helo=mxfep01.bredband.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FStCL-00020y-J8 for emacs-devel@gnu.org; Mon, 10 Apr 2006 06:00:41 -0400 Original-Received: from coolsville.localdomain ([83.226.180.152] [83.226.180.152]) by mxfep01.bredband.com with ESMTP id <20060410095553.DFGA16061.mxfep01.bredband.com@coolsville.localdomain> for ; Mon, 10 Apr 2006 11:55:53 +0200 Original-Received: (from jhd@localhost) by coolsville.localdomain (8.13.4/8.13.4/Submit) id k3A9t1cP028530 for emacs-devel@gnu.org; Mon, 10 Apr 2006 11:55:01 +0200 In-Reply-To: <200604090659.k396xI5h005539@scanner2.ics.uci.edu> Original-To: emacs-devel@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:52592 Archived-At: > ERROR > CID: 8 > Checker: DEADCODE (help) > File: emacs/src/xfns.c > Function: Fx_window_property > Description: After this line, the value of "actual_format" is equal to 32 > > 4327 if (rc == Success && tmp_data) > 4328 { > 4329 /* The man page for XGetWindowProperty says: > 4330 "If the returned format is 32, the returned data is represented > 4331 as a long array and should be cast to that type to obtain the > 4332 elements." > 4333 This applies even if long is more than 32 bits, the X library > 4334 converts from 32 bit elements received from the X server to long > 4335 and passes the long array to us. Thus, for that case bcopy can not > 4336 be used. We convert to a 32 bit type here, because so much code > 4337 assume on that. > 4338 > 4339 The bytes and offsets passed to XGetWindowProperty refers to the > 4340 property and those are indeed in 32 bit quantities if format is > 4341 32. */ > 4342 > > Event dead_error_condition: On this path, the condition "actual_format < 32" could not be true > Event new_values: Conditional "actual_format == 32" > Event const: After this line, the value of "actual_format" is equal to 32 > Also see events: [dead_error_begin][new_values][const] > > 4343 if (actual_format == 32 && actual_format < BITS_PER_LONG) > 4344 { It can not be < 32 if BITS_PER_LONG is 32, that is true. But for a 64-bit CPU BITS_PER_LONG is 64, so then it becomes relevant. It is only intended to be relevant for the BITS_PER_LONG == 64 case. I think gcc optimizes the code away if it finds that actual_format < BITS_PER_LONG can never be true. Jan D.