[c.limits] Remove an incorrect note about type of constant macros #667

k-satoda · 2016-03-30T16:15:52Z

The note implies that the types of constant macros defined in
may differ from that of C, but no nomative rule say so, and there is no
reason to allow such incompatibilities.

The note was added as the resolution of LWG issue #416.
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416
But the analysis, which based on rules of integer constants, was wrong:
The type of constant macros are defined in C99 (5.2.4.2.1 p1) by rules
of integer promotions. So LONG_MAX always has type long (integer
promotions has no effect for long), even if the actual range of long and
int are equal. That should hold in C++, too.

Please note that there is no such note for constant macros defined in
.

FYI, the tyepes of the constant macros are defined in C99 5.2.4.2.1, p1.

The values of these constants shall be ... . 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.

Integer promotions are defined as following in C99 6.3.1.1 p2.

The following may be used in an expression wherever an int or unsigned
int may be used:

An object or expression with an integer type whose integer
conversion rank is less than or equal to the rank of int and
unsigned int.

A bit-field of type _Bool, int, signed int, or unsigned int.
If an int can represent all values of the original type (as restricted
by the width, for a bit-field), the value is converted to an int;
otherwise, it is converted to an unsigned int. These are called the
integer promotions. All other types are unchanged by the integer
promotions.

I'm posting this here as an editorial issue because it is only a removal
of a "Note:" But I also have feeling that this should go as a LWG issue
because it reverts the resolution of an old LWG isseue. Please let me
know if someone know which is preferable.

The note implies that the types of constant macros defined in <climits> may differ from that of C, but no nomative rule say so, and there is no reason to allow such incompatibilities. The note was added as the resolution of LWG issue cplusplus#416. http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416 But the analysis, which based on rules of integer constants, was wrong: The type of constant macros are defined in C99 (5.2.4.2.1 p1) by rules of integer promotions. So LONG_MAX always has type long (integer promotions has no effect for long), even if the actual range of long and int are equal. That should hold in C++, too.

jwakely · 2016-03-30T16:20:44Z

But what about:

#  define SCHAR_MIN     (-128)
#  define SCHAR_MAX     127

Those do not have type signed char, and

#  define USHRT_MAX     65535

does not have type unsigned short.

k-satoda · 2016-03-30T16:36:11Z

Yes they should have type int as defined in C99.

std::cout << SCHAR_MAX << std::endl;

This should print "127", instead of ASCII DEL character. Same applies to
INT8_MAX, and so on.

If SCHAR_MAX really should have type signed char, C++ should have
normative and portable rules (unlike the current loose note) for them and
also for those defined in .

Do you want LWG issue for that? I think nobody want that.

jwakely · 2016-03-30T16:46:28Z

Yes they should have type int as defined in C99.

That's exactly what the note is saying. It says that SCHAR_MAX might not have type signed char.

Going back to your first comment:

The note implies that the types of constant macros defined in
may differ from that of C

No it doesn't. That's not what the note says.

k-satoda · 2016-03-30T17:21:25Z

Ah, ...

(quote from [c.limits])

The contents are the same as the Standard C library header <limits.h>.
[ Note: The types of the constants defined by macros in are
not required to match the types to which the macros refer. -end note ]

I misread "the type to which they refer" as "the type of them in the
Standard C library". But it was in fact "their corresponding type" (in
C terminology, for type-min/max constants). Right?

If so, is it obvious for native English readers? (I'm not.)

However, I suspect it is still preferable to remove the note , since the
reference C standard is now C99, which define the type of the constants
precisely. I think the note was somewhat effective with C90, which didn't
have definition of their types(this part was wrong: #667 (comment)) .
Having the note only on (not on ) is another reason.

sigfpe · 2016-03-30T17:49:17Z

Maybe, there is too much insistence that C++ must exactly copy C standardese word-for-word, or say nothing at all?
I find the note fine.-------- Original message --------From: Kazutoshi SATODA notifications@github.com Date: 3/30/2016 1:21 PM (GMT-05:00) To: cplusplus/draft draft@noreply.github.com Subject: Re: [cplusplus/draft] [c.limits] Remove an incorrect note about type
of constant macros (#667)
Ah, ...

(quote from [c.limits])

The contents are the same as the Standard C library header <limits.h>.

[ Note: The types of the constants defined by macros in are

not required to match the types to which the macros refer. -end note ]

I misread "the type to which they refer" as "the type of them in the

Standard C library". But it was in fact "their corresponding type" (in

C terminology, for type-min/max constants). Right?

If so, is it obvious for native English readers? (I'm not.)

However, I suspect it is still preferable to remove the note, since the

reference C standard is now C99, which define the type of the constants

precisely. I think the note was somewhat effective with C90, which didn't

have definition of their types. Having the note only on (not on

) is another reason.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

k-satoda · 2016-03-30T18:33:53Z

I'm sorry. My above comment "... C90, which didn't have definition of
their types" was wrong. The types were defined already in C90.

jwakely · 2016-03-30T23:45:11Z

I misread "the type to which they refer" as "the type of them in the
Standard C library".

That's wrong. That is not a valid interpretation of the note, and I don't think a fluent English speaker would read it that way.

But it was in fact "their corresponding type" (in
C terminology, for type-min/max constants). Right?

I'm not sure what you mean by "corresponding type". The type to which they refer means the type referred to by the name. INT_MAX refers to int, CHAR_MAX refers to char, etc.

I don't think "corresponding type" is any clearer or less ambiguous.

If so, is it obvious for native English readers? (I'm not.)

The meaning seems obvious to me.

I certainly don't think striking a note that LWG added to resolve a defect report is editorial.

k-satoda · 2016-03-31T02:11:07Z

Thank you very much for clarifications. Now I understood this PR was
clearly wrong.

I used "corresponding type" as it is used in the C standard to define
the type of min/max constants.

... have the same type as would an expression that is an object of the
corresponding type converted according to the integer promotions. ...

jwakely closed this Mar 30, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[c.limits] Remove an incorrect note about type of constant macros #667

[c.limits] Remove an incorrect note about type of constant macros #667

k-satoda commented Mar 30, 2016

jwakely commented Mar 30, 2016

k-satoda commented Mar 30, 2016

jwakely commented Mar 30, 2016

k-satoda commented Mar 30, 2016

sigfpe commented Mar 30, 2016

k-satoda commented Mar 30, 2016

jwakely commented Mar 30, 2016

k-satoda commented Mar 31, 2016

[c.limits] Remove an incorrect note about type of constant macros #667

[c.limits] Remove an incorrect note about type of constant macros #667

Conversation

k-satoda commented Mar 30, 2016

jwakely commented Mar 30, 2016

k-satoda commented Mar 30, 2016

jwakely commented Mar 30, 2016

k-satoda commented Mar 30, 2016

sigfpe commented Mar 30, 2016

k-satoda commented Mar 30, 2016

jwakely commented Mar 30, 2016

k-satoda commented Mar 31, 2016