Re: [Qemu-devel] [PATCH] use an unsigned long for the max_sz parameter in load_image_targphys

[Alexander Graf <agraf@suse.de>]

On 12.03.2012, at 16:53, Markus Armbruster wrote:

> Peter Maydell <peter.maydell@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