> >
> > 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
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.
Every input expression has a type, and just as with a normal function call,
that type is either compatible with the type signature of the aggregating
function, or not (a syntax error). If it is compatible, the Normal
Arithmetic Conversions are applied as part of passing that parameter:
i.e. you can cast (int)bar, but since the signature is uint64_t, the normal
conversions are applied to transform that int to uint64_t as per ISO C.
I can't see how we can change the type signatures of the aggregating functions
without breaking existing program behavior -- if you want signed versions of
these things, then we would need to introduce separate signed equivalents.
-Mike
--
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
_______________________________________________
dtrace-discuss mailing list
[email protected]
