Re: [PATCH] net: compare_ether_addr[_64bits]() has no ordering
From: Johannes Berg <johannes@sipsolutions.net>
Date: 2012-05-08 05:25:48
On Mon, 2012-05-07 at 19:20 -0400, David Miller wrote:
quoted
quoted
quoted
Neither compare_ether_addr() nor compare_ether_addr_64bits() (as it can fall back to the former) have comparison semantics like memcmp() where the sign of the return value indicates sort order. We had a bug in the wireless code due to a blind memcmp replacement because of this. A cursory look suggests that the wireless bug was the only one due to this semantic difference. Signed-off-by: Johannes Berg <redacted> --- include/linux/etherdevice.h | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)The right way to avoid this kind of problems is to change these functions to return a boolWell, I guess so, but that'd be a weird thing for a compare_ function... should probably be named equal_... then, but I'm not really able to do such a huge change on the first day after my vacation :-)It's true the name could be improved, but changing the name is quite a large undertaking even with automated scripts. Even the bool change is slightly painful, since all of the explicit tests against integers (%99.999 of these are in wireless BTW :-) would need to be adjusted.
I suppose I could fix those first and then later change the type, but I think having a "compare_ether_addr" function that returns *false* when they *match* would be rather confusing. I'd rather have "equal_ether_addr()" that returns *true* when they match. I guess we could introduce equal_ether_addr() though and slowly convert, keeping compare_ether_addr() as a sort of wrapper around it. johannes