emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem report #8 FALSE


From: Jan D.
Subject: Re: Problem report #8 FALSE
Date: Mon, 10 Apr 2006 11:55:01 +0200 (CEST)

> 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]