Hmm. It seems that both the OS vendor (IBM) who #defines LONG_MAX to
be of type int as well as myself have misread the C standard. Let me
get back to them and point them to this discussion to see if they
agree.

Martin

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Wed, 24 Mar 2004 09:15:44 +0000 (UTC), kuyper@wizard.net (James
Kuyper) wrote:

>gennaro_prota@yahoo.com (Gennaro Prota) wrote in message news:<k8ir50140ho1ao43ec167817sj80ukt1bu@4ax.com>...
>> >From the text of the DR:
>>
>>   The "corresponding type converted according to the integer
>>   promotions" for LONG_MAX is, according to 6.4.4.1, 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.
>
>LONG_MAX typically expands into an integer constant, and 6.4.4.1p5
>gives the rules that determine which type that constant does have.
>However, it's section 5.2.4.2.1p1 which determines which type that
>constant must have. It's correctly cited in the DR itself:

I didn't check this, as I though the reference was to the *C90*
standard. It's odd that they are referring C99, even if there are no
differences that affect the issue (who knows, until one verifies :)).

>> Section 5.2.4.2.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 thing that determines which type LONG_MAX must be, is "an
>expression that is an object of the corresponding type". That is not
>an integer constant

Right. Thanks for pointing this out.

>, as far as C is concerned. An "expression that is
>an object of" type 'long int' "converted according to the integer
>promotions", still has a type of 'long int'. Therefore, according to
>5.2.4.2.1, LONG_MAX must be an expression that has a type of 'long
>int'.
>
>An implementation where INT_MAX==LONG_MAX could meet this requirement
>using an explicit cast:

Well, no, it can't do this, as the expression must be usable in #if
directives.

>
>#define INT_MAX 2147483647
>#define LONG_MAX (long)2147483647
>
>However, an easier way is to use a type suffix of 'l' or 'L'.
>
>#define LONG_MAX 2147483647L
>
>Section 6.4.4.1p5 would still apply to such a literal, but because of
>the 'L' suffix, it has a shorter list than the one given in the DR:
>"long int, long long int". If LONG_MAX does have the correct type,
>then the DR becomes a dead issue. The committee response
><http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/lwg-active.html#416>
>suggests to me that they're unaware of this fact.

Thank you James. Incidentally, I think "an expression that is an
object" should actually be "an expression that designates an object";
but the intent is clear :)


Genny.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 22 Mar 2004 03:01:08 +0000 (UTC), gennaro_prota@yahoo.com
(Gennaro Prota) wrote:

> >From the text of the DR:
>
>   The "corresponding type converted according to the integer
>   promotions" for LONG_MAX is, according to 6.4.4.1, 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.
>
C99 6.4.4.1 or C90 6.1.3.2 concerns the type of >source< constants,
i.e. literals, and the quoted rule applies only to literals with no L
(or in C99 LL) suffix. Except that it's actually >width< (number of
value bits) that matters, not sizeof; these are not required to be
correlated, although in a sane universe they are.

The "corresponding type" for limits.h literals in 5.2.4.2 (in both C99
and C90) is clearly the type for which each limit is being defined,
i.e. /*signed*/ long for LONG_MIN, unsigned int for UINT_MAX, etc.
And as you correctly note these promotions do not change long, so
LONG_MAX must be long, whereas for example USHRT_MAX might be either
signed int or unsigned int.

Very minor nit: C90 called them 'integral promotions' and 'integral
types', as C++98 still does, versus 'integer' in C99, which is not
(yet) normative for C++.

> I don't have a copy of the C90 standard, but if it says that a long
> int can be 'promoted' to an int that's very likely a defect. C99
> clarifies that
>
>  - bitfields apart, only types with a lower 'conversion rank'
>    than int and unsigned int are changed by integer promotions
>    (6.3.1.1/2)
>
>  - long int has a higher conversion rank than int, even if
>    the 'precision' of the two types may be the same (6.3.1.1/1)
>
C90 didn't have the term 'conversion rank'; 6.2.1.1 explicitly lists
char, short, bit-fields, signed and unsigned, and enum types as the
only ones affected by the integral promotions. (And C90 6.2.1.5 on the
usual arithmetic conversions spells out all the cases, which were then
fewer because no long long or implementation-extended types, versus
C99 6.3.1.8 which refers to conversion rank.)

> Thus, the type of the expression that LONG_MAX expands to has to be
> long int.

- David.Thompson1 at worldnet.att.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

>From the text of the DR:

  The "corresponding type converted according to the integer
  promotions" for LONG_MAX is, according to 6.4.4.1, 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.

I don't have a copy of the C90 standard, but if it says that a long
int can be 'promoted' to an int that's very likely a defect. C99
clarifies that

 - bitfields apart, only types with a lower 'conversion rank'
   than int and unsigned int are changed by integer promotions
   (6.3.1.1/2)

 - long int has a higher conversion rank than int, even if
   the 'precision' of the two types may be the same (6.3.1.1/1)

Thus, the type of the expression that LONG_MAX expands to has to be
long int.



--
Genny.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

gennaro_prota@yahoo.com (Gennaro Prota) wrote in message news:<k8ir50140ho1ao43ec167817sj80ukt1bu@4ax.com>...
> >From the text of the DR:
>
>   The "corresponding type converted according to the integer
>   promotions" for LONG_MAX is, according to 6.4.4.1, 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.

LONG_MAX typically expands into an integer constant, and 6.4.4.1p5
gives the rules that determine which type that constant does have.
However, it's section 5.2.4.2.1p1 which determines which type that
constant must have. It's correctly cited in the DR itself:

> Section 5.2.4.2.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 thing that determines which type LONG_MAX must be, is "an
expression that is an object of the corresponding type". That is not
an integer constant, as far as C is concerned. An "expression that is
an object of" type 'long int' "converted according to the integer
promotions", still has a type of 'long int'. Therefore, according to
5.2.4.2.1, LONG_MAX must be an expression that has a type of 'long
int'.

An implementation where INT_MAX==LONG_MAX could meet this requirement
using an explicit cast:

#define INT_MAX 2147483647
#define LONG_MAX (long)2147483647

However, an easier way is to use a type suffix of 'l' or 'L'.

#define LONG_MAX 2147483647L

Section 6.4.4.1p5 would still apply to such a literal, but because of
the 'L' suffix, it has a shorter list than the one given in the DR:
"long int, long long int". If LONG_MAX does have the correct type,
then the DR becomes a dead issue. The committee response
<http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/lwg-active.html#416>
suggests to me that they're unaware of this fact.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]