[Bug c++/47706] New: std::min/max and NaN

[Bug c++/47706] New: std::min/max and NaN

[dieter.lucking at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47706

           Summary: std::min/max and NaN
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: dieter.lucking@googlemail.com


This seems to be a contradiction:

((0.0 < std::numeric_limits<double>::quiet_NaN()) ? 0.0 :
std::numeric_limits<double>::quiet_NaN()) => `nan'

std::min(0.0, std::numeric_limits<double>::quiet_NaN()) => `0'

[Bug c++/47706] std::min/max and NaN

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47706

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-02-12 01:38:07 UTC ---
There is nothing to fix here. I suppose you agree that any comparison involving
NaNs is false, thus you first example is ok. The second one invokes undefined
behavior, because among the requirements of std::min is that the type T must be
LessThanComparable and when you instantiate std::min with a floating point T
including NaNs in its domain the '<' isn't irreflexive.

[Bug c++/47706] std::min/max and NaN

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47706

--- Comment #2 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-02-12 01:54:53 UTC ---
Never mind the second half of my comment, the issue has nothing to do with
irreflexivity of course.

The point is, in the implementation of std::min the comparison fails and the
first argument is returned, because the standard wants the first argument if
the arguments are equivalent. Given the latter requirement + only
LessThanComparable is required, I don't see how the behavior could be
different.