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.

-- 
Christian "naddy" Weisgerber                          [EMAIL PROTECTED]

Reply via email to