Re: Use of sized ints

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 3 Mar 2017, at 13:17, Frediano Ziglio <fziglio@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]