> > On 3 Mar 2017, at 13:17, Frediano Ziglio < fzig...@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. Actually with int16 I was just kidding. > > :-) > > > 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 So the question was between nt, unsigned and uint32. You are suggesting unsigned as portably and potentially faster than uint32. On the other way we don't support CHAR_BIT != 8 and we don't support 16 bit architectures so unsigned at to be at least 32 bit. Currently it's the same as an uint32, in case it grows the canonic -1 value won't work as potentially -1 != (unsigned) (uint32) -1 so perhaps would be better to use int. In doubt a surface_id_t typedef could help. Frediano
_______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
