[Spice-devel] Use of sized ints

[Frediano Ziglio]

> > 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.

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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20170306/6bedab95/attachment-0001.html>