Re: [Xen-devel] libxl and unsigned types

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.03.12 at 17:02, George Dunlap <George.Dunlap@xxxxxxxxxxxxx> wrote:
> 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.

I hadn't seen one, and the mail archive doesn't show one either.
Or did you mean IanJ's reply above (in which case I continue to be
of a different opinion, and hope I won't be forbidden to use unsigned
types namely in hypervisor code - if on the tools side maintainers
decide to do so I guess I'll have to try to cope with that)? Or is ijc not
equivalent to IanC?

Jan


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