Peter Maydell <peter.mayd...@linaro.org> writes: [...] > Putting a "restrict to INT_MAX" in the highbank code is definitely > wrong (not least because passing values to load_image_targphys isn't > the only thing we use that field in arm_boot_info for!) > The ARM boot code needs updating because it shouldn't be > using 'int' for arm_boot_info.ram_size, and using target_phys_addr_t > the same as we do for initrd_size is the obvious thing. I have no > particular objection to having some new target_phys_size_t or whatever, > and I could be persuaded that we should follow the memory API in > using uint64_t for sizes, but it needs to be a type that either follows > guest phys addr restrictions or a fixed-width type which we have decreed > is always large enough,
There is already a type that is defined to be wide enough for any object size: size_t. > not a type which varies based on host properties. To be honest, the whole debate feels like bikeshedding to me. Yes, load_image_targphys()'s argument max_sz is the size of a slice of guest memory. It's also the size of a host object, allocated with g_malloc0() in rom_add_file(). It's also the size of a disk file. I'd make it size_t and be done with it. If you absolutely must overengineer things, go ahead and create a new type for target sizes. I doubt making it wider than size_t will work in practice without a lot of hoop jumping, though. [...]
