[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] libxl and unsigned types



On Wed, 2012-03-14 at 16:14 +0000, Jan Beulich wrote:
> >>> 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?

gwd meant iwj and not ijc ;-)

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®.