Re: Minor net/core/sock.c security issue?

["Albert D. Cahalan" <acahalan@cs.uml.edu>]

David S. Miller writes:

> In short, min/max usage is pretty broken.  And it is broken for
> several reasons:
>
> 1) Signedness, what you have discovered.
>
> 2) Arg evaluation.
>
> 3) Multiple definitions
...
> There is even commentary about this in include/linux/netfilter.h along
> with Rusty's attempt to make reasonable macros.  I personally disagree
> with keeping them as macros because of the arg multiple evaluation
> issues.
>
> I think the way to fix this is to either:
> 
> 1) have standard inline functions with names that suggest the
>    signedness, much like Rusty's netfilter macros.
>
> 2) Just open code all instances of min/max, there will be no
>    mistaking what the code does in such a case.
>
> In both cases, min/max simply die and nobody can therefore misuse them
> anymore.

The macros won't die. You could make global ones like this:

#define min(a,b) Never do this due to signed/unsigned issues.
#define max(a,b) Never do this due to signed/unsigned issues.
#define MIN(a,b) Never do this due to signed/unsigned issues.
#define MAX(a,b) Never do this due to signed/unsigned issues.

Long term, __builtin_min() and __builtin_max() would be nice.
I'm guessing the g++ <? and >? operators don't handle signs right,
but in case they do then that is an even better option.