[Spice-devel] Use of sized ints

[Christophe de Dinechin]

> On 3 Mar 2017, at 13:17, Frediano Ziglio <fziglio at redhat.com> wrote:
> 
>> 
>> We have recently discussed the use of the bool type. What about sized int
>> types? What is the policy here?
>> 
>> Notably, on a part of the code I’m presently working on, I saw that
>> surface_id could be either an int or an uint32_t. There is apparently no
>> clear winner:
>> 
>> $ git grep "int.*surface_id" | wc
>>     141     659   12350
>> $ git grep "uint32.*surface_id" | wc
>>      89     434    8182
>> 
>> So this means roughly 63% uint32 and 36% “other ints”…
>> 
>> In your opinion, for new code, should I use unsigned, int or uint32 for a
>> surface_id parameter? (My personal vote would be unsigned)
>> 
>> 
>> Christophe
> 
> int16 !

Actually, the reason I vote for ‘unsigned’ is to use a “base” machine type. I think for parameters and local variables (i.e. stuff that ideally lives in registers and not memory) it’s better.

> 
> :-)
> 
> I think on the network they are sent using uint32 however in some code -1
> (so basically 0xffffffff) is assumed the invalid standard value.
> Other invalid values (<0 or >maximum) are discarded (the entire command
> is discarded). The maximum is 1000 so in some way int16 would even make sense!

Yes, but if you use int16 as an argument, you force the machine to compute on 16 bits. On x86, it’s relatively OK, there are 16-bit opcodes for everything since it started as a 16-bit ISA. But on ARM, PPC or other machines, the compiler may end up emitting additional code (things like “zero extend” or “sign extend” instructions) to make sure you only observe 16-bit values. So int16 makes sense for a struct field or a pointer type, rarely for parameters or locals. It does not hurt that much either, though.

Christophe

> 
> Frediano
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org <mailto:Spice-devel at lists.freedesktop.org>
> https://lists.freedesktop.org/mailman/listinfo/spice-devel <https://lists.freedesktop.org/mailman/listinfo/spice-devel>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20170303/683787e3/attachment-0001.html>