Use u_long instead of uint32_t variables to avoid overflow on 64-bit architectures.
Details
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
My only concern is if we can really trust u_long to be 64-bit on every platform. I can see that MIPS64 defines uint64_t as "long long" in one case. I'm not knowledgeable enough to tell if the MIPS part is even compiled now or if "unsigned long" won't work there, but it might be safer to use a type that is guaranteed to be 32/64b, like uintptr_t or vm_offset_t.
We could use uintptr_t too, but perhaps it would be better to stay with the convention used in other fdt_common functions - they all use u_long for memory addresses. All these functions would fail if u_long was 32-bit on some 64-bit arch. All rman functions also (currently) use u_long type arguments which contain memory addresses.
According to mips/include/_types.h, MIPS32 defines uint64_t as unsigned long long, MIPS64 defines it as unsigned long, and I think other archs are consistent.
Ok, as we discussed locally, let's leave u_long for now. All its instances in fdt stuff are going to be replaced anyway, so it's better to be consistent with the rest of the file now.