[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] libxl and unsigned types
Jan Beulich writes ("Re: [Xen-devel] [PATCH] libxl: don't accept negative disk or partition indexes"): > I would call this surprising only if you think purely mathematically > (which you shouldn't when programming in any language that uses > finite width data types). I think this is a coding style question. It isn't addressed in CODING_STYLE and the current code is (as ever) inconsistent, but we should make a specific decision and stick to it for new changes at least. > Instead I find it rather natural to actively use those properties > that you call surprising, and in particular to use unsigned types > for variables that can't (or shouldn't) have negative values The problem is that the cannot-be-negative property doesn't just apply to the type (eg, count) in question. It also propagates to values derived from it by arithmetic. Attempts, for example, to calculate remaining space, or differences of any kind, go badly wrong. I think the correct approach is to use signed types and, at appropriately points, explicitly limit incoming values to small enough subsets of their types that arithmetic overflow cannot occur anywhere. > (not the least because this tends to produce better > code, as no sign-extension is necessary when using such variables > e.g. as array indexes). This is not a consideration in libxl because libxl doesn't contain hot paths. > Plus I'd be curious where you would see fit > for unsigned types (or whether you consider them evil altogether). They are useful for bitfields, values whose abstract types are circular orders, and the like. Not things which are supposed to model a subset of the mathematical integers. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |