[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-ports
Subject:    Re: POLICY: Fixing all visible 64-bit issues
From:       "Federico G. Schwindt" <fgsch () lodoss ! net>
Date:       2008-06-29 14:02:45
Message-ID: 20080629140245.GH5333 () vnv
[Download RAW message or body]

On Sat, Jun 28, 2008 at 04:21:55PM +0000, Christian Weisgerber wrote:
> The sysutils/xbatt problem was a reminder that 64-bit related bugs
> are still all over the ports tree.  fgsch@ has prodded me again and
> after wavering over this for years, I think it is time to declare
> a ZERO-TOLERANCE POLICY ON VISIBLE 64-BIT BUGS and embark on a
> concerted campaign to eradicate them in all ports, old and new.
> 
> By "visible" I mean that when you build a port on a 64-bit arch,
> you get one of these compiler warnings:
> 
>   warning: assignment makes integer from pointer without a cast
>   warning: assignment makes pointer from integer without a cast
>   warning: cast from pointer to integer of different size
>   warning: cast to pointer from integer of different size
> 
> *All* of these warnings must be examined.  They are generally due
> to one of two scenarios:
> 
> (1) Assignments pointer -> int -> pointer.
>     These are the bugs we want to find.  They must be fixed.
> 
> (2) Assignments int -> pointer -> int.
>     These aren't pretty, but they don't cause problems.
> 
> In order to start a comprehensive clean-up, we'll grep the bulk
> build logs for these warnings.  There are a lot.
> 
> Unfortunately, type (2) issues will show up as false positives,
> which suggests we should silence these warnings. (Easily done with
> proper casts.)  I am very worried that people will screw up and
> silence warnings for type (1) problems instead of fixing them, but
> I don't see an alternative.  Marking ports as audited for 64-bit
> bugs is not robust with our update churn.
> 
> I'm willing to hear some comments on whether we should silence
> innocuous warnings or not.
> 
> PS:
> It is not intuitively obvious, but scenario (2) is surprisingly
> common.  It usually appears in the context of APIs that take callback
> functions, which are called with a generic void* argument that can
> be used to pass arbitrary data.  Often, only an int needs to be
> passed and instead of allocating the memory for one and passing the
> pointer, it is a common shortcut to just cast the int directly to
> and from the pointer.

  For what is worth, I think this is the right way to go, although I'm
also afraid that people will screw up. In most of the cases I've seen,
the problems arise from missing includes, thus silently truncating the
returning types to int. This is easy to fix. Other cases may require
more work, it's hard to tell.
  I'll say let's start marking somehow the other cases, and slowly work
towards fixing them, but pushing for this to be fixed when it has not
been the case for so long will rush people to commit unproper fixes.
  My 2 cents.
 
  f.-

[prev in list] [next in list] [prev in thread] [next in thread]