> Alexander Kolbasov writes:
> > > Alexander Kolbasov writes:
> > > > Filed
> > > >
> > > > 6624541 dtrace aggregations should assume signed arguments
> > >
> > > Perhaps a silly question ... but why not just follow the signedness of
> > > the argument provided?
> > >
> > > If the user provides an unsigned data type to the aggregation, then do
> > > unsigned arithmetic on it. If he provides a signed type, do signed
> > > arithmetic.
> >
> > This would be nice, but I don't know whether DTrace framework allows
> > passing
> > argument types to aggregation functions.
>
> I'm not sure I understand.
>
> If I say this:
>
> @foo[execname] = sum(bar);
>
> Doesn't 'bar' have some type, at least by default? I had thought that
> dtrace tracked types dynamically. It seems to do so when I cast a
> value and assign it to "self->blah". It also seems to keep track of
> types if I try to pass in something that can't work.
>
> Why doesn't the expression have a type?
IMO values are uint64_t by default. You can say
@foo[execname] = sum((int)bar)
But, aggregation functions in common/dtrace/dtrace.c look like this:
/*ARGSUSED*/
static void
dtrace_aggregate_avg(uint64_t *data, uint64_t nval, uint64_t arg)
{
data[0]++;
data[1] += nval;
}
so even if the argument type information is available somewhere it is not
passed to agregation implementation. I don't know how involved is passing the
type information into various aggregation routines.
- akolb
_______________________________________________
dtrace-discuss mailing list
[email protected]
