New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[climits.syn] Correct note about types of macros #5926
Conversation
This note was added apparently as a response to LWG 416 (https://cplusplus.github.io/LWG/issue416). However, the submitter of that issue misunderstood the C standard. The required types are not the types that would be produced by an unadorned integer literal, but rather those produced by the integer promotions. Thus, only the macros for (signed|unsigned)? char and (unsigned)? will have a different type. And this is what actual implementations do: https://godbolt.org/z/5E1MojhGh. Accordingly, the note, as currently written, is at best misleading, because it implies that all the macros may have types that don't match.
What we have is "The types of the constants defined by macros in \libheader{climits} are not Is that an incorrect summary of the C standard? Do you have a cross reference to the C standard to cross-check that statement? |
ISO C 5.2.4.2.1 states, "The values given below [of the macros defined by <limits.h>] 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 ISO C 6.3.1 describes the integer promotions: "The following may be used in an expression wherever an I consider the current wording to be inaccurate because some of the macros are required to have the same type as the type to which they refer (namely, those referring to int, long, long long, and their unsigned variants). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with the problem statement. Could the suggested new wording be shortened by omitting "that refer to types of integer conversion rank less than that of int
"? The statement is true for all of them, it's just that the integer promotions don't change the type for INT_MAX
, LONG_MAX
etc.
And why isn't MB_LEN_MAX
mentioned in your suggested rewording?
I have removed the reference to conversion rank, but still felt that we need a phrase to explain what types the integral promotions are applied to. I also added |
I find this wordy. Also, can we make that singular for extra precision? Suggestion:
|
Looks good -- @jwakely? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works for me.
This note was added apparently as a response to LWG 416 (https://cplusplus.github.io/LWG/issue416). However, the submitter of that issue misunderstood the C standard. The required types are not the types that would be produced by an unadorned integer literal, but rather those produced by the integer promotions. Thus, only the macros for (signed|unsigned)? char and (unsigned)? will have a different type. And this is what actual implementations do: https://godbolt.org/z/5E1MojhGh.
Accordingly, the note, as currently written, is at best misleading, because it implies that all the macros may have types that don't match.