On 12.03.2012, at 16:53, Markus Armbruster wrote: > 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.
I agree. Let's end this discussion and use the biggest variable type we support for addresses: uint64_t. That way we have host independent predictability, but don't use _addr_t types which Andreas seems to dislike. Alex
