> > Because an error is being returned and it's not clear that qpi_data should > > actually mean anything in that case. > > It doesn't suffice just to check that *mp is not null? How can *mp > be valid and qpi_data invalid?
Easily ? > > I wouldn't expect a pfil_func thing to be returning < 0. > > Problem is a pfil_func thing might be buggy and it'd be nice to > limit the amount of unexpected behavior (leaving the byte ordering > mucked in this situation just encourages more unexpected behavior). > I view executing ip = qpi->qpi_data prior to checking err as a form > of belt and suspenders. Using the same argument, I would say that if err != 0, how do you know that qpi_data is actually accurate ? MAYBE if err != 0 and the mblk pointer hasn't changed, then it might be safe to fiddle the byte ordering. But I think what would be better is if pfil converted return values of pfil_func that are < 0 to be > 0, ensuring that there's no confusion passed back to the callers of pfil_prel_precheck. That would properly refine pfil_precheck's return values of "< 0" to be "i don't think this is a datagram, pass it on". Darren
