Swift Griggs <swiftgriggs%gmail.com@localhost> writes: > On Fri, 16 Dec 2016, Christos Zoulas wrote: >> audio_get_port+0x7e is this line: >> return sc->hw_if->get_port(sc->hw_hdl, mc); >> I don't see how we can get there with sc->hw_if being NULL.. >> Add some printfs to see what's NULL... > > I've been staring at this in sys/dev/audio.c and trying to learn from > this situation. I have some ignorant (because I'm not a kernel coder > and only have about 30k lines of C under my belt) questions: > > If nobody cares, that's cool. It was just an exercise for me. > > * Why not check the input values in au_get_lr_value() ? It appears to > blindly use the first two input structures without checking if they are > null. So does au_get_gain() and others. Does that kind of thing slow the > driver down too much or is the input checked elsewhere before being > passed?s Generally, we use KASSERT(pointer != NULL), and then with "options DIAGNOSTIC" that is checked and a panic happens. Basically this both documents things that we know must be true and actually checks them. KASSERT compiles to nothing if DIAGNOSTIC is not enabled. So the KASSERTs are only not present because no one added them. > * Dunno where get_port() comes from but shouldn't it also check it's first > argument (a struct) for NULL? Sure. I suggest: adding options DIAGNOSTIC adding KASSERT rebuilding trying it
Attachment:
signature.asc
Description: PGP signature