[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC] CODING_STYLE: document intended usage of types
>>> On 19.02.18 at 12:46, <ian.jackson@xxxxxxxxxx> wrote: > Jan Beulich writes ("[PATCH RFC] CODING_STYLE: document intended usage of > types"): >> +Types >> +----- >> + >> +Use basic C types and C standard mandated typedef-s where possible (and >> +with preference in this order). This in particular means to avoid u8, >> +u16, etc despite those types continuing to exist in our code base. >> +Fixed width types should only be used when a fixed width quantity is >> +meant (which for example may be a value read from or to be written to a >> +register). > > This should have more practical advice, in the form of examples. In > particular, what types should be used for guest and host addreses in > various contexts ? Types to be used for addresses - from a really generic pov - depend on the architecture. Iirc there are some where a signed type is the more natural representation, while on x86 and ARM we'd certainly use "unsigned long". Since guests may be of different bitness, specifying what type to use for their addresses would go too far anyway imo. > Also, what assumptions should be made about the sizes of standard > types ? Should "short" be used when the value is known to fit in 16 > bits ? I think we should discourage (but not forbid) the use of short and (except for strings) char. I think we can (and I also think we actively do) assume int to have at least 32 bits, and long to be as wide as a pointer. All of these are not coding style aspects, just like ... > In this context it would probably also be worth mentioning that the > programmer may assume that the machine is two's-complement and has > 8-bit bytes. ... any of this isn't, either. Hence I don't think this belongs here. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |