[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |