From the redhat web page:
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gcc/offsetof.html
__offsetof__ (expression)
is equivalent to the parenthesized expression, except that the
expression is considered an integral constant expression even if
it contains certain operators that are not normally permitted in
an integral constant expression. Users should never use __offsetof__
directly; the only valid use of __offsetof__ is to implement the
offsetof macro in <stddef.h>.
g++-3 does not have a built-in offsetof(), but we cannot use the c version,
otherwise we break with -Wold-style-cast.
Inspired by the DF version, but a bit different.
- Arrays can now be externalized and internalized in the same way
dictionaries can.
- Add new "externalize to file" and "internalize from file" functions
to make reading a property list from a file and writing a property
list to a file more convenient.
- Many assertions in the object implementations are gone. Instead,
calling an accessor for one object type with a different object type
as an argument will return a suitable "invalid" value.
- prop_object_type() now returns a new PROP_TYPE_UNKNOWN value if called
with a NULL object.
- Externalized property lists now contain a reference to the Apple XML
plist DTD.
- Add a new prop_ingest(3) facility, which provides a convenient way to
translate a dictionary into an arbitrary binary representation.
an Amiga DMA controller, and #if 0'ed WD33C93 definitions that are duplicated
in sbicreg.h. uPD71071 definitions can stay for now, since they're not
actually useless even though they're unused.
evidence that this is actually needed except for the existence of the
code itself, but if it's going to be here, it should compile. Tested
briefly on my ASUS motherboard with built-in sk interface.
RISC OS and look for a matching mode in a list of standard
video modes. This removes the requirement for compiling
RISC OS monitor definitions into the kernel. [bjh21 20060820]
the nearest one, rather than the first one with the same resolution. This
is likely to be useful when the bootloader finally passes a valid frame rate.
For now, it just favours flickery over non-functional.
While it can be made to compile, the paradigm is not quite right because
it attempts to contact the filesystem during autoconfig which sometimes
causes a panic. Even if that was fixed, there is another potential problem
in that the driver tries/sleeps/tries/sleeps and the sleep could
theoretically sleep past the rc.d/btconfig stage and the controller
would remain unconfigured.
So, I have prepared a different method for loading the firmware to
Broadcom BCM2033 chip based devices. A package 'sysutils/bcmfw' will load
the firmware files via a ugen(4) device interface.
This update removes the ubtbcmfw(4) driver and adds a table to the ubt(4)
driver so that it will not attach to Broadcom BCM2033 based devices before
the firmware was loaded.
This fixes kern/34219
