* Use the preferred time source (GetTimeSource) for the node
* Fix node releasing when creating the connection fails
* Add virtual slots and padding
* Refactor _Connect method
* offsetof is not allowed on non-POD types so we need to use
offset_of_member (gcc2 accepts offsetof, and C++11 relaxed the
constraints on where it is allowed so it should work there too)
* we have offset_of_member as a workaround until we switch to C++11,
move it from khash (which is soon to be removed) to list.h which is the
other place where it is used (for this one single call in our whole
codebase)
Also fix a typo in vfs.cpp.
* The HIG uses "Options" while all bundled Haiku apps consistently use
"Settings". Make the HIG match the real world on this.
* Replace ... with the correct … for menu item samples.
* Some 80-column formatting on the touched paragraphs.
Thanks to Janus for spotting this in #11733.
Since the package information is refreshed asynchronously, some packages
may fit the current filter parameters. Check for this situation more
generically in the MSG_PACKAGE_CHANGED notification. Before, it was only
done for prominent packages to make them appear in the Featured packages
view. The problem was visible by for example selecting a category and then
refreshing packages. Many of the previously shown packages would be missing
and magically appear when changing filter parameters slightly and back
to what they were.
* Network speed was previously always shown as Kb/s, now it can switch
to Mb/s when needed.
* Fixes#11053.
Signed-off-by: Adrien Destugues <pulkomandy@gmail.com>
When trying to find a matching parent item, we cannot rely on cached
pointers to BPackageEntries, since those are re-used per entry level
from the BPackageReader. Instead, we build the package entry path as
a string and store that with the list item.
Removed debug output.
Fix for CVE-2014-3571
Fix for CVE-2015-0206
Fix for CVE-2014-3569
Fix for CVE-2014-3572
Fix for CVE-2015-0204
Fix for CVE-2015-0205
Fix for CVE-2014-8275
Fix for CVE-2014-3570
It is only useful for ACPI devs. If the need ever arise it can
easily be reworked to be enabled / disabled at runtime.
For everyone else it was just syslog garbage.
* This ioctl is used only in the arp command, but still we should keep
it working
* Similar to the problem in elf.cpp, this relied on entry being set to
NULL when trying to iterate after the last element.
The refactored version of Unflatten() encapsulated the raw buffer
into a BMemoryIO with a specified size of SIZE_MAX, since the total
size of the messageisn't known up front. On 32-bit this was no problem,
but on x86_64, this would lead to an overflow in BMemoryIO, since it
stores its internal length as a size_t, which on that platform is the same
size as off_t. Consequently, when it would cast its length to off_t to
compare against the requested seek position in ReadAt/WriteAt, this would
overflow to a negative, leading it to reject all requests, which
subsequently caused Unflatten() to fail.
As a result of the refactoring for OpenHashTable, the iterator semantics
have changed a bit, such that the end of the table is no longer signalled
by the iterator returning NULL. This wasn't taken into account during
refactoring, which would lead to various places returning the last item
in the list in the case where no matching item was found, causing e.g.
drivers not to be loaded properly. This fixes the boot hang regressions
introduced in hrev48640.
Most changes were in the PackageContentOutliner and its HandleEntry() method
to make it work correctly. The parent entry of a visited entry may not be
the last parent entry, but some other previously added entry. We need a
PackageEntryItem class to also store the BPackageEntry together with the
list item.
Other small fixes.
* Replaced the hash function as it wasn't really useful. It seems better
to use the full in_addr_t as a hash as it is a 32bit value. Shuffling it
like the previous hash function did can only increase the number of
collisions.
* BOpenHashTable lacks the "range" parameter to the hash function, so we
can't know which bits from the hash are actually going to be used.
