Re: C standard question?

On Wed, 7 May 2008 13:23:50 -0700 (PDT), Tomás Ó hÉilidhe
<toe@xxxxxxxxxxx> wrote in comp.lang.c:

I should have read your reply all the way to the end before my first
response. You made several errors.

On May 7, 8:20 pm, Eric Sosman <Eric.Sos...@xxxxxxx> wrote:

        unsigned int ui = (unsigned int)uc << 24;


You wouldn't believe how many people do the likes of the following:

char unsigned uc1, uc2;

uc1 = 72;

uc2 = ~uc1;

1) uc1 gets promoted to a signed int

On many implementations, perhaps including all those you have ever
used, uc1 gets promoted to signed int. There are implementations were
uc1 will get promoted to unsigned int because UCHAR_MAX is greater
than INT_MAX.

2) The complement is gotten of this signed int

Of course, on implementations where uc1 is promoted to unsigned int,
the result of the complement is also an unsigned int.

3) When the signed int is converted back to unsigned char, the
behaviour is implementation defined.

This is completely wrong regardless of whether unsigned char promotes
to signed or unsigned int. Assignment of the value of a higher rank
integer type, whether signed or unsigned, to a lesser rank unsigned
integer type is 100% completely defined by the C standard. There is
absolutely no implementation-defined behavior involved.

There's no problem on a two's complement system, and of course most
systems are two's complement, but still I'd definitely go with:

uc2 = ~(unsigned)uc1;

On implementations where unsigned char promotes to signed int, the
result of the complement is either a trap representation or
implementation-defined, and that is regardless of the type of
representation for negative signed integers. But if the complement
does not produce undefined behavior by generating a trap
representation, the assignment to unsigned char is always
well-defined.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
.

Relevant Pages

  • Re: casting
    ... Your code assumes that int and unsigned int are 32 bits (something not ... signed int b = 4294967295U; ... On most implementations, the conversion will yield the value -1. ...
    (comp.lang.c)
  • Re: C standard question?
    ... On many implementations, perhaps including all those you have ever ... uc1 gets promoted to signed int. ... he mentioned the promotion of unsigned char to signed int. ...
    (comp.lang.c)
  • Re: Does casting lvalue lead to Undefined Behaviour ?
    ... an unsigned int. ... There is no possibility for a trap representation. ... converted to, not reinterpreted as, a signed int, which results in an ... implementations to declare the result is undefined (as it would be in ...
    (comp.lang.c)
  • Re: Problems with formatted input.
    ... > This code successfully reads -1 into an unsigned int. ... > implementations of STL fail to read -1 into an unsigned int, ... With sufficient thrust, pigs fly just fine. ...
    (microsoft.public.vc.language)
  • Re: GCC bitfield packing
    ... The actual amount of storage taken us depends only upon the number of ... depend upon the type of the bitfield declaration. ... _Bool, int, signed int, and unsigned int. ...
    (comp.std.c)