On Tue, Jul 12, 2011 at 4:54 PM, Adam Leventhal <a...@delphix.com> wrote: > Hey Bryan, > > Did you consider having the behavior be that if the third argument was > greater than the second (unsigned) that it would generate an error?
Yeah, I did consider that and we had a conversation about that here. The consensus was that implicitly clamping it was the cleaner behavior -- that the closest analogue here was the clamping behavior of strsize (where you don't see an error, just a silent clamping) and that you don't want to see the console flooded with error messages in the case where it's consistently larger than the static size. What are your thoughts? > Regarding tst.dynsize.d, could the output fail to match if the tick > probe switched CPUs? Is that sufficiently unlikely, or would it be > worth using a profile probe with a cpu predicate (caching the first > value we see)? Yeah, that's true -- but unlikely, as you say. FWIW, that's true in many places in the test suite. In fact there was a port of DTrace out there that changes the CPU on which the tick probe fires on every firing, and the test suite fell over in a zillion places. So if this is a problem that we want to tackle, I think we might want to do it somewhat holistically... > { "tracemem", DT_IDENT_ACTFUNC, 0, DT_ACT_TRACEMEM, > DT_ATTR_STABCMN, DT_VERS_1_0, > - &dt_idops_func, "void(@, size_t)" }, > + &dt_idops_func, "void(@, size_t, ...)" }, > > I think that should be: "void(@, size_t, [size_t])" like copyinstr() or > index(). I could have done in that way, but I'm actually doing the check manually because I want to propagate my own error tag and test on it. Thanks for taking a look at this -- and I only have two more wads to come! (They're both tiny.) - Bryan _______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org