> > > 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.
> >
> > As Bryan mentioned earlier, quantize()/lquantize() also treat their
> > arguments
> > as uint64_t but in the kernel implementation convert it to int64_t. Can the
> > same thing be done for max()/min()/avg()?
> >
> > - akolb
>
> Not without breaking program compatibility, because the type signatures
> we assigned to the aggregating functions also determine the default
> base that is used when printf()'ing an aggregation, and therefore would
> break the output of programs that rely or desire the unsigned behavior.
Mike and I just talked about this -- he didn't realize that we already
have precedent for doing this in the fix (and patch) for 6320439.
And because we print aggregation results out as signed 64-bit values (that
is "dtrace -n BEGIN'{ @ = max(-10); exit(0); }'" does what you think it
should), the only D program that this could break would be one relying
on aggregating values above 2^63 -- and as Chad pointed out, these
can silently overflow and break anyway.
So I think we can go ahead and fix that bug as filed. And yes, passing
the type information down to the kernel would be a cleaner way of doing
it -- but that's also a hell of a lot more work, and it only benefits
those that are aggregating values greater than 2^63...
- Bryan
--------------------------------------------------------------------------
Bryan Cantrill, Sun Microsystems FishWorks. http://blogs.sun.com/bmc
_______________________________________________
dtrace-discuss mailing list
[email protected]
