Re: [Xen-devel] libxl and unsigned types

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Wed, Mar 14, 2012 at 11:22 AM, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> 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.

FWIW, overall ijc's proposal seems sensible to me.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel