User Details
- User Since
- Jun 2 2022, 8:42 PM (214 w, 18 h)
Sep 16 2022
- Remove trailing tabs
- Style fixes, mainly cuddle comments and add newlines at end of file
- Lock behind LOADER_EDITING_SUPPORT option
- Don't clobber extended ASCII
Sep 14 2022
- Add license comments
- Remove __FBSDID, fix style, use ctype functions for parsing
Jun 14 2022
Don't allow invalid values for -f, fix typo, replace "shadow" with "overlap" in usage
Add compatibility section, clarify a few options, cut down on some repetition
I've added the compatibility section, and I realized that almost all of the options work together, so I changed it to only mention options which aren't compatible instead.
Jun 10 2022
Make suggested changes, squash shadowing commit and warning commit
I totally forgot that I need to update the revision when I make a new commit, sorry about the delay!
Update man page for pruning byte default and the concept of shadowing
Jun 6 2022
Alright, sounds good to me. This definitely isn't an urgent change so I'll switch to pruning by default and get the man page updated, then this should be good to go.
My only worry with pruning by default is breaking any existing uses. Despite how unlikely it is that someone built a script/automation around usbdump output with conflicting filters, there's a chance that their filters were wrong but seemed to work thanks to shadowing.
Don't AND filters, but do try to correct/warn when filters might end up having unexpected results.
I've thought about this more, and I think that the real problem is that OR-ing a unit and unit.endpoint filter for the same unit isn't intuitive, since the lone unit filter will always match and make the unit.endpoint filter pointless. I'm not sure if it is fair to expect someone writing a filter to know this and avoid unit.-1 filters when using unit.endpoint or -1.endpoint filters though (and the implicit unit filter for -d ugenX.Y muddies the waters a bit more).
So, I've come up with two potential solutions:
Jun 4 2022
Hmm, looking back the same "bug" is present in match_filter and dates all the way back to the initial commit for the utility, so you're right about it being intentional. I had always been invoking with the full -d argument which implicitly added a X.-1 filter for -d ugenY.X, which was why I was so convinced it was wrong (as far as I could at the time, no matter what was entered for -f it had no effect).
Jun 3 2022
Oops, yeah, I got a bit caught up in following the template that I wasn't sure what all to include.
Split into seperate commits.
