From: "Albert D. Cahalan" <acahalan@cs.uml.edu>
Message-Id: <200107240302.f6O32iB279266@saturn.cs.uml.edu>
Subject: Re: Minor net/core/sock.c security issue?
To: davem@redhat.com (David S. Miller)
Date: Mon, 23 Jul 2001 23:02:44 -0400 (EDT)
Cc: chris@scary.beasts.org (Chris Evans), linux-kernel@vger.kernel.org
In-Reply-To: <15196.45004.237634.928656@pizda.ninka.net> from "David S. Miller" at Jul 23, 2001 04:14:20 PM
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Original-Recipient: rfc822;linux-kernel-outgoing

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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/