Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
>
> James Kuyper <kuyper@wizard.net> writes
> > That's because every non-negative 'int' is guaranteed to fit in
> > 'unsigned'; that's not necessarily true for 'long'.
>
> IIRC all non-negative values of long are required to be
> representable as unsigned long.  [...]

Just as an aside: James did say `unsigned', not `unsigned long'.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <38AB9779.4D149160@wizard.net>, James Kuyper
<kuyper@wizard.net> writes
>That's because every non-negative 'int' is guaranteed to fit in
>'unsigned'; that's not necessarily true for 'long'.
IIRC all non-negative values of long are required to be representable as
unsigned long.  What we discovered (on the C Committee) was that the
C89/90 rules did not require that all values of unsigned int could be
represented by an unsigned long. short<=int<=long coupled with the
requirements for representation of the values in the corresponding
unsigned type does not allow the deduction that ushort<=uint<=ulong.

That is so bizarre that it went unnoticed AFAIK until about 1997.  The
new standard corrects this oddity.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <38AD91EC.5066@despam.pangea.ca>, Harvey Taylor
<het@despam.pangea.ca> writes
>       Sorry I am having trouble gettin my head around this.
>       Can anyone post an example.

I am not surprised.  However here is an example (please not that this is
pure language law and has little to do with any realistic
implementation)

All integer types are stored in 64-bit storage but padding is used.

short : 16-bits + 48 bits padding  unsigned short : 64 bits
int : 24 bits + 24 bits padding    unsigned int   : 48 bits + 16 bits
                                                         padding
long : 32 bits + 32 bits padding   unsigned long  : 32 bits + 32 bits
                                                        padding

I think the above meets all the requirements of C89/90 even though no
unsigned type can represent the whole range of a lower ranked unsigned
type.  Yes it takes some fairly warped thinking to see recognise this
bug in the original specifications. C99 should have fixed this.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I think the standard is just covering itself against non-32-bit platforms.
My recollection is that C has the same rules.

"long OP unsigned" will be long if unsigned is smaller because unsigned
values can be held in a long without loss of information. This is value-
preserving.

It will be unsigned if long is the same size, which is the basis of the rule
of thumb that says C promotes mixed arithmetic to unsigned. This is not
value-preserving. (This case always applies to "int OP unsigned" since
"int" is always the same size as "unsigned".)

The second case is an arbitrary language design decision in C. I think C
made the wrong choice, since unsigned arithmetic has snares for naive
users, but it is about 30 years too late to change it.

"Gene Bushuyev" <gbush@my-deja.com> wrote in message
news:samicu7c2pd37@corp.supernews.com...
> Is there a reason why the standard defines asymmetrical rules for binary
> operators that involve long and int. If I'm reading 5p9 correctly the
result
> of "long OP unsigned" can be either long or unsigned long. While the
result
> of "int OP unsigned" is always unsigned. Isn't it also different from the
> ANSI C that I believe always produces long for the former?
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Gene Bushuyev wrote:
>
> Is there a reason why the standard defines asymmetrical rules for binary
> operators that involve long and int. If I'm reading 5p9 correctly the result
> of "long OP unsigned" can be either long or unsigned long. While the result
> of "int OP unsigned" is always unsigned. ...

That's because every non-negative 'int' is guaranteed to fit in
'unsigned'; that's not necessarily true for 'long'.

> ... Isn't it also different from the
> ANSI C that I believe always produces long for the former?

I don't know what C89 said, but the new C99 standard says in section
6.3.1.8 p1:

"Otherwise, if the operand that has unsigned integer type has rank
greater or equal to the rank of the type of the other operand, then the
operand with signed integer type is converted to the type of the operand
with unsigned integer type."

This doesn't apply, since "unsigned int" has lower rank than "long int".
The following clause applies if LONG_MAX >= UINT_MAX:

"Otherwise, if the type of the operand with signed integer type can
represent all of the values of the type of the operand with unsigned
integer type, then the operand with unsigned integer type is converted
to the type of the operand with signed integer type."

While this clause applies if LONG_MAX < UINT_MAX:

"Otherwise, both operands are converted to the unsigned integer type
corresponding to the type of the operand with signed integer type."

While thi

That's fairly complicated wording, but I think it's compatible with C++
5 p9.

> This can have unexpected effect on overload resolution and other operations.
> Below is the example that demonstrates the problem. Several compilers that I
> tried all converted "unsigned + long" expression to unsigned long regardless
> of the values, so I have a suspicion that I misunderstood something in the

The values of the operands are irrelevant; what matters is the range of
values supported by the types of the operands, not the particular values
themselves.

> standard. Any clarification would be appreciated.
>
> #include <iostream>
>
> void f(long int){ std::cout<<"long int\n";}
> void f(unsigned int){std::cout<<"unsigned int\n";}
> void f(unsigned long){std::cout<<"unsigned long\n";}
>
> void foo(unsigned i)
> {
....
>   // But this one is puzzling in the light of 5p9.
>   // how can compiler know what function to call
>   // in this case?
>   f(i + 0l); // f(unsigned long) or f(long) ???

The compiler knows whether or not 'long' can hold all the values allowed
for 'unsigned'. Based upon that knowledge, it knows which type to use in
evaluating the sum, and that type determines which function to call.

....
>   if(1l - 2u >0) // must be false

Not if LONG_MAX>UINT_MAX.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Gene Bushuyev wrote:
>
> Is there a reason why the standard defines asymmetrical rules for binary
> operators that involve long and int. If I'm reading 5p9 correctly the result
> of "long OP unsigned" can be either long or unsigned long. While the result
> of "int OP unsigned" is always unsigned. Isn't it also different from the
> ANSI C that I believe always produces long for the former?

Given that sizeof(int)==sizeof(long) is allowed (and indeed quite
common), how should (unsigned)UINT_MAX * (long)1 give a valid long
on such implementations?

> This can have unexpected effect on overload resolution and other operations.
> Below is the example that demonstrates the problem. Several compilers that I
> tried all converted "unsigned + long" expression to unsigned long regardless
> of the values, so I have a suspicion that I misunderstood something in the
> standard. Any clarification would be appreciated.

Of course the type of the result is independant from the actal
values. Everything else would be a nightmare.

[...]

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ken Hagan wrote:
>
> I think the standard is just covering itself against non-32-bit platforms.

Yes. It's also covering itself against non-16-bit platforms; and
non-36-bit platforms. The standard has a bias in favor of power-of-2
sizes, but doesn't require them, and it certainly isn't intended to
imply that any one particular size is the default, with other sizes as
optional alternatives. Rather the opposite.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]