Re: [IDEA+RFC] Possible solution for min()/max() war

[Herbert Rosmanith]

> From: Helge Hafting <[e-mail]>
> X-Mailer: Mozilla 4.76 [no] (X11; U; Linux 2.4.10-pre1 i686)
> X-Accept-Language: no, en
> To: Brad Chapman <[e-mail]>, [e-mail]
> Subject: Re: [IDEA+RFC] Possible solution for min()/max() war
> References: <[e-mail]>
> Sender: [e-mail]
> Precedence: bulk
> X-Mailing-List: 	[e-mail]
> 
> Brad Chapman wrote:
> > 
> > Then why, IIRC, are the kernel hackers so upset about how
> > the three-arg macros _prevent_ signed/unsigned comparisons?
> > Apparently the ability to compare
> > signed/unsigned variables must have _some_ significance....
> 
> You are misunderstanding this.
> It is possible to write something that _looks like_ a signed to unsigned
> comparison, i.e.:
> int a;
> unsigned int b;
> ...
> x = min(a,b);
> 
> Looks like a signed to unsigned comparison - but it isn't!
> 
> You see, the compiler always does an _implicit_ cast in cases like this.
                             ^^^^^^^^^^^^^^^^^^^^^

if that's your concern, we can easily fix this by still moving min/max
to its same form.

#define type_min(type,x,y) \
        ({ type __x = (x), __y = (y); __x < __y ? __x: __y; })
#define type_max(type,x,y) \
        ({ type __x = (x), __y = (y); __x > __y ? __x: __y; })

#define min(x,y) type_min(typeof(x),x,y)
#define max(x,y) type_max(typeof(x),x,y)

no _implicit_ cast and ...

> One of the arguments gets changed invisibly, and that is what kernel
> developers are so upset about.  You don't really know which one without
> thinking hard about it, and that is a source of many hard-to-find bugs.

... joy, we would even know which one.

-- 
mfg,
Dipl.-Ing. H.Rosmanith                    Karrer & Partner Gesellschaft mbH
Freistaedter Str. 236, A-4040 Linz,                   Tel. [phone]
                                                      Fax. [phone]