> Michael Shapiro writes: > > Every aggregating function has to have a defined, fixed type, that > > determines > > how its implementation in kernel and userland, a portion of which is quoted > > above, performs the underlying arithmetic. Since our original release, the > > type signatures of the aggregating functions to which you are referring > > have their signature as: sum(uint64_t arg), and so on. > > Ah, that's too bad. > > The Fortran intrinsics I was referring to are essentially polymorphic > functions (yes, 20-odd years before O-O) that look like this: > > uint64_t sum(uint64_t); > int64_t sum(int64_t); > > ... where the compiler picks the right function (there are actually > two or more) based on the context. It'd be pretty helpful here, and a > shame if it can't be done.
That can certainly be done, it just isn't the way it works now. That too can break program compatibility if someone was assuming at present that signed data is converted to unsigned by virtue of conversion in the absence of an explicit cast, but we have a versioning mechanism in DTrace that can be used to handle this type of upgrade. Sasha: either close the bug you filed, or change it to an RFE requesting that we either introduce a signed alternative, implemented either as another choice of aggregating function name or the above polymorphism. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/ _______________________________________________ dtrace-discuss mailing list [email protected]
