[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.