summaryrefslogtreecommitdiffstats
path: root/contrib/expat/lib
diff options
context:
space:
mode:
authorian <ian@FreeBSD.org>2016-01-24 22:00:36 +0000
committerian <ian@FreeBSD.org>2016-01-24 22:00:36 +0000
commit650a9addf1aa6411b6dfefe94fcf78fe0b856fe8 (patch)
tree9ab101a5aad57290be783adabad116d206466c4d /contrib/expat/lib
parent33902405d5bbd7b2931c254ec445012ce3f55107 (diff)
downloadFreeBSD-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
OpenPOWER on IntegriCloud