diff options
author | ian <ian@FreeBSD.org> | 2016-01-24 22:00:36 +0000 |
---|---|---|
committer | ian <ian@FreeBSD.org> | 2016-01-24 22:00:36 +0000 |
commit | 650a9addf1aa6411b6dfefe94fcf78fe0b856fe8 (patch) | |
tree | 9ab101a5aad57290be783adabad116d206466c4d /contrib/expat/lib | |
parent | 33902405d5bbd7b2931c254ec445012ce3f55107 (diff) | |
download | FreeBSD-src-650a9addf1aa6411b6dfefe94fcf78fe0b856fe8.zip FreeBSD-src-650a9addf1aa6411b6dfefe94fcf78fe0b856fe8.tar.gz |
MFC r293053, r293061, r293063, r293064, r293065, r293775, r293792:
Use 64-bit math when finding a block of ram to hold the kernel. This fixes
a problem on 32-bit systems which have ram occupying the end of the physical
address space -- for example, a block of ram at 0x80000000 with a size of
0x80000000 was overflowing 32 bit math and ending up with a calculated size
of zero.
Use 64-bit math when processing the lists of physical and excluded memory
to generate the phys_avail and dump_avail arrays.
Work around problems that happen when there is ram at the end of the
physical address space.
Cast pointer through uintptr_t on the way to uint64_t to squelch a warning.
Reword the comment to better describe what I found while researching the
problem that led to this temporary workaround (and also so I can properly
cite the PR in the commit this time).
Cast using uintfptr_t and eliminate the cast to uint64_t which is uneeded
because rounding down cannot increase the number of bits needed to express
the result.
Go back to using uintptr_t, because code that actually compiles is
infinitely less buggy than code that is theoretically correct in some
alternate universe.
PR: 201614
Diffstat (limited to 'contrib/expat/lib')
0 files changed, 0 insertions, 0 deletions