Section [4.7], Integral conversions, seems to imply that the return
value of f() is implementation-defined:

int f()
{
  int x = -1;
  unsigned int y = x;

  return y;
}

The value of y is welled defined by [4.7.2] -- it is "the least
unsigned integer congruent to the source integer (modulo 2n where n is
the number of bits used to represent the unsigned type)".  However,
the conversion back to an int, in the return statement has
implementation-defined results:

3 If the destination type is signed, the value is unchanged if it can be
  represented  in the destination type (and bit-field width); otherwise,
  the value is implementation-defined.

It this interpretation correct?

This also seems to imply that the value returned by g() is also
implementation-defined.  However, the value returned by h() is well
defined (w.r.t. the bit width of unsigned integers...)

int g()
{
  unsigned int x = 1;
  int y = -2;

  return x + y; // x and y promoted to unsigned ints by arithmetric
                // conversions.
}

unsigned int h()
{
  unsigned int x = 1;
  int y = -2;

  return x + y; // x and y promoted to unsigned ints by arithmetric
                // conversions.
}

Since there is already the restriction on implementations w/o a 2's
complement representation of signed ints for the signed -> unsigned
conversion, why not have a similar restriction for the unsigned ->
signed conversion?


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <FREYBURG.96May16121123@gamut.stanford.edu>
freyburg@gamut.stanford.edu (Brian Michael Freyburger) writes:

> Since there is already the restriction on implementations w/o a 2's
> complement representation of signed ints for the signed -> unsigned
> conversion, why not have a similar restriction for the unsigned ->
> signed conversion?

Because no one gave the committee a compelling reason to be
incompatible with C in this respect.
--
    --Andrew Koenig
      ark@research.att.com
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]