Re: macro conflict

From: Richard B. Johnson (root@chaos.analogic.com)
Date: Fri Aug 24 2001 - 08:34:06 EST


On Fri, 24 Aug 2001, David Woodhouse wrote:

>
> twalberg@mindspring.com said:
> > There has already been **much** discussion about this, but I think
> > that the bottom line is that the new version is safer and more robust
> > than the old version, and thus is not likely to be changed back.
>
> That's a completely separate issue. You can fix it while keeping sane
> semantics for min() and max().
>
> #define real_min(x,y) ({ typeof((x)) _x = (x); typeof((y)) _y = (y); (_x>_y)?_y:_x; })
>
> #define min(x,y) ({ if strcmp(STRINGIFY(typeof(x)), STRINGIFY(typeof(y))) BUG(); realmin(x,y) })
>
> /me wonders if gcc would manage to optimise that.
> --
> dwmw2
>

Looking through the code, min() is most always used to find some value
that will not overflow some buffer, i.e.,

    len = min(user_request_len, sizeof(buffer));

The problem is that sizeof() returns an unsigned int (size_t), and the
user request length may be an integer. Everything works fine until
you get to lengths with the high bit set. Then, you are in trouble.

In this case, you could have a 'min()' that does:

#define min(a,b) (unsigned long)(a) < (unsigned long)(b) ? (a) : (b)

... where the comparison (only) is made unsigned, and you keep the
original values. This should work, perhaps in all the current uses.
However, min() is not the mathematical min() anymore. That's fine,
but it probably should not be called min() unless it is truly a min()
function.

So, I suggest that instead of using some macro in a header, if you
need min() you make one in your code called MIN(). Problem solved.
Your macro will do exactly what you want it to do. If It's broken,
you get to fix it (or keep the pieces).

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

-
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/



This archive was generated by hypermail 2b29 : Fri Aug 31 2001 - 21:00:09 EST