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

[Markus Armbruster]

Peter Maydell <address@hidden> 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.

[...]