This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of CD1 status.
Section: 17.3.6 [climits.syn] Status: CD1 Submitter: Martin Sebor Opened: 2003-09-18 Last modified: 2017-06-15
Priority: Not Prioritized
View all issues with CD1 status.
Given two overloads of the function foo(), one taking an argument of type
int and the other taking a long, which one will the call foo(LONG_MAX)
resolve to? The expected answer should be foo(long), but whether that
is true depends on the #defintion of the LONG_MAX macro, specifically
its type. This issue is about the fact that the type of these macros
is not actually required to be the same as the the type each respective
Section 18.2.2 of the C++ Standard does not specify the exact types of the XXX_MIN and XXX_MAX macros #defined in the <climits> and <limits.h> headers such as INT_MAX and LONG_MAX and instead defers to the C standard.
Section 188.8.131.52.1, p1 of the C standard specifies that "The values [of these constants] shall be replaced by constant expressions suitable for use in #if preprocessing directives. Moreover, except for CHAR_BIT and MB_LEN_MAX, the following shall be replaced by expressions that have the same type as would an expression that is an object of the corresponding type converted according to the integer promotions."
The "corresponding type converted according to the integer promotions" for LONG_MAX is, according to 184.108.40.206, p5 of the C standard, the type of long converted to the first of the following set of types that can represent it: int, long int, long long int. So on an implementation where (sizeof(long) == sizeof(int)) this type is actually int, while on an implementation where (sizeof(long) > sizeof(int)) holds this type will be long.
This is not an issue in C since the type of the macro cannot be detected by any conforming C program, but it presents a portability problem in C++ where the actual type is easily detectable by overload resolution.
[Kona: the LWG does not believe this is a defect. The C macro definitions are what they are; we've got a better mechanism, std::numeric_limits, that is specified more precisely than the C limit macros. At most we should add a nonnormative note recommending that users who care about the exact types of limit quantities should use <limits> instead of <climits>.]
Change [c.limits], paragraph 2:
-2- The contents are the same as the Standard C library header <limits.h>.