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

["Christopher Friesen" <cfriesen@nortelnetworks.com>]

Brad Chapman wrote:
> 
> Mr. Schwab,
> 
> --- Andreas Schwab <schwab@suse.de> wrote:
> > Brad Chapman <kakadu_croc@yahoo.com> writes:
> >
> > |> Everyone,
> > |>
> > |>    From reading this thread, I believe I have come up with several reasons,
> > |> IMHO, why the old min()/max() macros were not usable:
> > |>
> > |>    - They did not take into account non-typesafe comparisons
> > |>    - They were too generic
> > |>    - Some versions, IIRC, relied on typeof()
> > |>    - They did not take into account signed/unsigned conversions
> > |>
> > |>    I have also discovered one problem with the new three-arg min()/max()
> > |> macro: it forces both arguments to be the same, thus preventing signed/unsigned
> > |> comparisons.
> >
> > There is no such thing as signed/unsigned comparision in C.  Any
> > comparison is either signed or unsigned, depending on whether the common
> > type of arguments after applying the usual arithmetic conversions is
> > signed or unsigned.
> 
>         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....

Are they?  The most salient objections I've seen are to do with compatibility
and code maintenance.

Since the underlying hardware has to compare either signed or unsigned numbers,
you will always have to eventually cast to some common type.  The three arg
macro simply makes it explicit *what* that common type is.

-- 
Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com