google
Hook and Priority cannot be directly compared with predefined values
Hi,
When obtaining chains using methods such as ListChains, the hookFromMsg method directly returns a new pointer, which prevents it from being directly compared with defined values in the package (e.g., ChainHookPrerouting or ChainPriorityNATDest). In actual use, it is necessary to first determine whether this pointer is nil, then dereference the pointer and check if they are the same. To be honest, this is quite cumbersome. For this, I think we could add some small features:
- Add an
Equals(*ChainXXX) boolmethod for*ChainHookand*ChainPrioritytypes. - Modify the logic of
hookFromMsgto directly return the defined value instead of creating a new pointer. - Implement both of the above solutions to facilitate the determination of custom values (e.g.,
Priority).
What do you think?
I think adding an Equals method is fine, but I would rather not modify the return signature because that would mean all current users of this method would need to update their code.
Sorry, maybe I didn't explain it well. What I meant was to modify the logic in hookFromMsg to directly return a predefined value such as ChainHookPrerouting, for example:
func hookFromMsg(b []byte) (*ChainHook, *ChainPriority, error) {
// ...
var hooknum *ChainHook
var prio *ChainPriority
for ad.Next() {
switch ad.Type() {
case unix.NFTA_HOOK_HOOKNUM:
switch v := ChainHook(ad.Uint32()); v {
case unix.NF_INET_PRE_ROUTING:
hooknum = ChainHookPrerouting
// ...
default:
hooknum = &v
}
case unix.NFTA_HOOK_PRIORITY:
switch v := ChainPriority(ad.Uint32()); v {
case -400:
prio = ChainPriorityConntrackDefrag
// ...
default:
prio = &v
}
}
}
return hooknum, prio, nil
}
Oh, so, in other words, guarantee pointer identity. The downside is that we need to handle all values individually. I think I prefer the Equals method.