Are the variables on the righthand side of an assignment statement
treated strictly as values? That is, if in assigning to an "unsigned
int" I shift a "unsigned char" 24 places to the left, can I trust that
the compiler will use temp storage sufficient to hold the "unsigned
int" and NOT result in an overflow (because I shifted an "unsigned
char" 24 places)?

Using gcc I tried the code below:

#include <stdio.h>

int main( int argc, char *argv[] )
{
unsigned char c[ 4 ] = { 0xff, 0xff, 0xff, 0xff };
unsigned int ui;

ui = (c[ 3 ] << 24) | (c[ 2 ] << 16) | (c[ 1 ] << 8) | c[ 0 ];
fprintf( stderr, "ui = %x\n", ui );
}

and got:

> ui = ffffffff

But validation through compilation is a dangerous thing!

---jski

jan.chludzinski@gmail.com wrote:
> Are the variables on the righthand side of an assignment statement
> treated strictly as values?

No, but mostly yes. In right-hand sides like `&x' or
`sizeof x', the variable `x' is used only for its location
or for its type, not for its value. But in "arithmetic"
right-hand sides like `x + 3' or `x << 2' or just `x', the
variable's value is used.

> That is, if in assigning to an "unsigned
> int" I shift a "unsigned char" 24 places to the left, can I trust that
> the compiler will use temp storage sufficient to hold the "unsigned
> int" and NOT result in an overflow (because I shifted an "unsigned
> char" 24 places)?

No. The assignment target -- the left-hand side -- does
not influence how the right-hand side is evaluated. On most
systems[*] your `unsigned char' value will be promoted to a
plain (signed) `int', which will then be shifted left 24 places.
There'll be trouble if `int' has 24 or fewer bits (16, for
example), or if the shift tries to slide a non-zero bit from
a value position into the sign position.

What you need is

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

.... and this still contains the assumption that `int' is at
least 25 bits wide.
[*] Exception: On "exotic" systems like some digital signal
processors, characters and ints have the same width and an
`unsigned char' promotes to an `unsigned int' instead.

> Using gcc I tried the code below:
>
> #include <stdio.h>
>
> int main( int argc, char *argv[] )
> {
> unsigned char c[ 4 ] = { 0xff, 0xff, 0xff, 0xff };
> unsigned int ui;
>
> ui = (c[ 3 ] << 24) | (c[ 2 ] << 16) | (c[ 1 ] << 8) | c[ 0 ];
> fprintf( stderr, "ui = %x\n", ui );
> }
>
> and got:
>
>> ui = ffffffff

You were lucky. Or maybe unlucky.

> But validation through compilation is a dangerous thing!

I'd have said "unreliable" rather than "dangerous," but
the sentiment is right.

--
Eric.Sosman@sun.com

jan.chludzinski@gmail.com wrote, On 07/05/08 19:44:
> Are the variables on the righthand side of an assignment statement
> treated strictly as values?

That is not the question you intended to ask. I think you wanted to know
if they are treated as values of the same type as the left hand side,
and the answer is no.

> That is, if in assigning to an "unsigned
> int" I shift a "unsigned char" 24 places to the left, can I trust that
> the compiler will use temp storage sufficient to hold the "unsigned
> int" and NOT result in an overflow (because I shifted an "unsigned
> char" 24 places)?
>
> Using gcc I tried the code below:
>
> #include <stdio.h>
>
> int main( int argc, char *argv[] )
> {
> unsigned char c[ 4 ] = { 0xff, 0xff, 0xff, 0xff };
> unsigned int ui;
>
> ui = (c[ 3 ] << 24) | (c[ 2 ] << 16) | (c[ 1 ] << 8) | c[ 0 ];

Each array element will be promoted to either int (if UCHAR_MAX <=
INT_MAX) or unsigned int (if INT_MAX < UCHAR_MAX <= UINT_MAX). Since the
latter is probably the case on your gcc implementation c[3]<<24 invoked
undefined behaviour.

> fprintf( stderr, "ui = %x\n", ui );
> }
>
> and got:
>
>> ui = ffffffff
>
> But validation through compilation is a dangerous thing!

Indeed, as the behaviour is undefined in this case it was "luck" you got
the answer you expected. You should cast to the correct unsigned type.
Also be aware that (unsigned) int could be only 16 bits.
--
Flash Gordon

On May 7, 8:20pm, Eric Sosman <Eric.Sos...@sun.com> 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
2) The complement is gotten of this signed int
3) When the signed int is converted back to unsigned char, the
behaviour is implementation defined.

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;

jan.chludzinski@gmail.com wrote:
>
> Are the variables on the righthand side of an assignment statement
> treated strictly as values? That is, if in assigning to an
> "unsigned int" I shift a "unsigned char" 24 places to the left,
> can I trust that the compiler will use temp storage sufficient to
> hold the "unsigned int" and NOT result in an overflow (because I
> shifted an "unsigned char" 24 places)?
>
> Using gcc I tried the code below:
>
> #include <stdio.h>
> int main( int argc, char *argv[] ) {
> unsigned char c[ 4 ] = { 0xff, 0xff, 0xff, 0xff };
> unsigned int ui;
>
> ui = (c[ 3 ] << 24) | (c[ 2 ] << 16) | (c[ 1 ] << 8) | c[ 0 ];
> fprintf( stderr, "ui = %x\n", ui );
> }
>
> and got: ui = ffffffff

That only worked because the default int in your system was a 32
bit quantity. You need to ensure that the various c[n]s are
converted to a 32 bit quantity before shifting, i.e. cast them to
unsigned long (not int), as in: "((unsigned int)c[3] << 24) |
((unsigned int)c[3] << 16) ...".

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.


** Posted from http://www.teranews.com **

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

> On May 7, 8:20pm, Eric Sosman <Eric.Sos...@sun.com> 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;

I would have a hard time believing that any people in the world other
than you write the ridiculous "char unsigned".

--
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

On Wed, 7 May 2008 13:23:50 -0700 (PDT), Tomás Ó hÉilidhe
<toe@lavabit.com> 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:20pm, Eric Sosman <Eric.Sos...@sun.com> 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

In message
<29f39e17-0907-4e1c-aa89-945f767874f8@f36g2000hsa.googlegroups.com>,
Tomás Ó hÉilidhe <toe@lavabit.com> writes
>On May 7, 8:20pm, Eric Sosman <Eric.Sos...@sun.com> 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;

Is that legal?

I have seen it on a very old 8051 cross compiler but it was changed to
the conventional "unsigned char" over a decade ago and I have not seen
any other compiler that used it.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Chris H said:

> In message
> <29f39e17-0907-4e1c-aa89-945f767874f8@f36g2000hsa.googlegroups.com>,
> Tomás Ó hÉilidhe <toe@lavabit.com> writes
<snip>
>>
>> char unsigned uc1, uc2;
>
> Is that legal?

Yes. See 3.5.2 of C89: "the type specifiers may occur in any order".

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

On May 8, 4:44am, Jack Klein <jackkl...@spamcop.net> wrote:

> > 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.


Yes, I'm aware. My post was a follow-up to Eric Sosman's post in which
he mentioned the promotion of unsigned char to signed int.


> > 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.


Correct. Just to be pedantic:

The complement of a signed int is a signed int.
The complement of an unsigned int is 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.


Sorry yes, you're right. Conversion from signed to unsigned happens
the same way on every system. I'd gotten confused with converting
unsigned to signed. For instance the behaviour of the following is
implementation defined:

int i = 72;
unsigned j = UINT_MAX;

i = j; /* The value that this puts in 'i' is
totally up to the compiler */


> > 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,


The only implementation-defined thing about it is the amount of 1's at
the start of it, depending on the amount of value-representational
bits in it. We can be sure what's happening with 8 least significant
bits though, regardless of whether is signed or unsigned.


> 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.


Yes it is.

On May 8, 4:35am, Jack Klein <jackkl...@spamcop.net> wrote:

> I would have a hard time believing that any people in the world other
> than you write the ridiculous "char unsigned".


Have you taken an IQ test lately? Let's see if you can answer this
question:

Which two of these sentences convey the same information?

1) Today I saw a small dog beside the fence.
2) John takes sugar in his tea.
3) Beside the fence, I saw a small dog today.
4) Berlin is the capital of Germany.

If you're too mentally retarded to answer that question correctly then
you'll probably too imcompetent of a programmer to read other people's
code.

On May 10, 6:55pm, Tomás Ó hÉilidhe <t...@lavabit.com> wrote:

> you'll

typo: you're

Tomás Ó hÉilidhe wrote:
> On May 8, 4:44 am, Jack Klein <jackkl...@spamcop.net> wrote:
>
>>> 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.
>
>
> Yes, I'm aware. My post was a follow-up to Eric Sosman's post in which
> he mentioned the promotion of unsigned char to signed int.

... and in which I explicitly mentioned the possibility
of promotion to unsigned int instead. Nice of you to take
the time to repeat repeat repeat it it it.

--
Eric Sosman
esosman@ieee-dot-org.invalid

In message <6padnQFOKdUXQbjVRVnyhwA@bt.com>, Richard Heathfield
<rjh@see.sig.invalid> writes
>Chris H said:
>
>> In message
>> <29f39e17-0907-4e1c-aa89-945f767874f8@f36g2000hsa.googlegroups.com>,
>> Tomás Ó hÉilidhe <toe@lavabit.com> writes
><snip>
>>>
>>> char unsigned uc1, uc2;
>>
>> Is that legal?
>
>Yes. See 3.5.2 of C89: "the type specifiers may occur in any order".

ISO C90 has been superseded several times. Is it still legal?

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Chris H said:

> In message <6padnQFOKdUXQbjVRVnyhwA@bt.com>, Richard Heathfield
> <rjh@see.sig.invalid> writes
>>Chris H said:
>>
>>> In message
>>> <29f39e17-0907-4e1c-aa89-945f767874f8@f36g2000hsa.googlegroups.com>,
>>> Tomás Ó hÉilidhe <toe@lavabit.com> writes
>><snip>
>>>>
>>>> char unsigned uc1, uc2;
>>>
>>> Is that legal?
>>
>>Yes. See 3.5.2 of C89: "the type specifiers may occur in any order".
>
> ISO C90 has been superseded several times. Is it still legal?

Yes. For one thing, there's nothing illegal about writing C90 programs,
despite the existence of a later Standard, largely unimplemented. For
another, look up 6.7.2 of C99. (You're on the ISO C Committee, yes? You
*wrote* the Standard. You really ought to know what's in it.)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Tomás Ó hÉilidhe said:

> On May 8, 4:35 am, Jack Klein <jackkl...@spamcop.net> wrote:
>
>> I would have a hard time believing that any people in the world other
>> than you write the ridiculous "char unsigned".
>
>
> Have you taken an IQ test lately?

Have you taken a clue test lately? I have a hard time believing you can
reasonably expect Jack to answer any of your many C questions after you've
addressed him like that...

<snip>
>
> If you're too mentally retarded

....or that. And his killfile will not be the only one to which you've
managed to gain entry with that masterly display of how not to be a
diplomat.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Chris H <chris@phaedsys.org> wrote [re "char unsigned":
>
> ISO C90 has been superseded several times. Is it still legal?

C90 has only been superseded once, although it has also been amended
(once) and corrected (twice). The superseding document (C99) has also
been corrected (thrice), but not amended.

Yes, it's still valid (it was never "illegal"); 6.7.2p2 still contains
the same text as C90 did.

-- Larry Jones

Why can't I ever build character in a Miami condo or a casino somewhere?
-- Calvin

In message <2PydnWu3q6iMe7jVnZ2dnUVZ8uKdnZ2d@bt.com>, Richard Heathfield
<rjh@see.sig.invalid> writes
>Chris H said:
>
>> In message <6padnQFOKdUXQbjVRVnyhwA@bt.com>, Richard Heathfield
>> <rjh@see.sig.invalid> writes
>>>Chris H said:
>>>
>>>> In message
>>>> <29f39e17-0907-4e1c-aa89-945f767874f8@f36g2000hsa.googlegroups.com>,
>>>> Tomás Ó hÉilidhe <toe@lavabit.com> writes
>>><snip>
>>>>>
>>>>> char unsigned uc1, uc2;
>>>>
>>>> Is that legal?
>>>
>>>Yes. See 3.5.2 of C89: "the type specifiers may occur in any order".
>>
>> ISO C90 has been superseded several times. Is it still legal?
>
>Yes. For one thing, there's nothing illegal about writing C90 programs,
>despite the existence of a later

True. I asked if the char unsigned was legal and you said yes in the
1989 ANSI standard. So I asked if it was still legal. (We are now on ISO
C 1999 + TC1,2 and 3 and I cant remember all the changes and things
that were left in for K&R compatibility etc.

> Standard, largely unimplemented.

I agree with that.

>For
>another, look up 6.7.2 of C99.
Thanks. Where specifically. I can't see it scanning through

>(You're on the ISO C Committee, yes?
yes

>You
>*wrote* the Standard.
No I am one of many who contributed.

>You really ought to know what's in it.)
Not really. I have a life. I don't memorise all of it. It don't need
to.

It is like saying the person who designed the interior lights for a car
should know the specification of the metal in the engine block because
they worked on the car. .
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On May 10, 7:21pm, Richard Heathfield <r...@see.sig.invalid> wrote:

> And his killfile will not be the only one to which you've
> managed to gain entry with that masterly display of how not to be a
> diplomat.


And good job I'm not a diplomat, isn't it. I don't have to accomodate
people who are dickheads to me, which Mr Klein has been on more than
one occassion. That's the great thing about being a living, breathing
individual.

Also, I'm not your child and I don't seek any form of adoption, so if
you really want to be some sort of father or caring figure then you're
better off directing your attention at someone else.

I'm here to converse about C, not deal with mentally retarded
dickheads that are too stupid to get their head around a simple re-
ordering of words. And I'll re-iterate on that again: You TRULLY are
of extremely limited intelligence if you can't get your head around
"unsigned char" versus "char unsigned".

Oh, and if you have a killfile yourself, kindly add me to it, or at
the very least only respond to me if you've something to say about C.

Tomás Ó hÉilidhe wrote:
> [...]
> I'm here to converse about C, not deal with mentally retarded
> dickheads [...]

May all your conversations be as pleasant as this example.

--
Eric Sosman
esosman@ieee-dot-org.invalid

In article <abb1ff15-45a2-40fb-aa0e-c7aa7149b81f@8g2000hse.googlegroups.com>,
Tomás Ó hÉilidhe <toe@lavabit.com> wrote:

>I'm here to converse about C

The evidence suggests otherwise.

-- Richard
--
:wq

Tomás Ó hÉilidhe wrote:
> Jack Klein <jackkl...@spamcop.net> wrote:
>
>> I would have a hard time believing that any people in the world
>> other than you write the ridiculous "char unsigned".
>
> Have you taken an IQ test lately? Let's see if you can answer this
> question:
>
> Which two of these sentences convey the same information?
>
> 1) Today I saw a small dog beside the fence.
> 2) John takes sugar in his tea.
> 3) Beside the fence, I saw a small dog today.
> 4) Berlin is the capital of Germany.
>
> If you're too mentally retarded to answer that question correctly
> then you'll probably too imcompetent of a programmer to read other
> people's code.

I think you should go off in some corner and reconsider your
attitude. After this I, and I suspect many more, are about || so
close to PLONKing you.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.


** Posted from http://www.teranews.com **

Tomás Ó hÉilidhe <toe@lavabit.com> writes:
[...]
> I'm here to converse about C, not deal with mentally retarded
> dickheads that are too stupid to get their head around a simple re-
> ordering of words. And I'll re-iterate on that again: You TRULLY are
> of extremely limited intelligence if you can't get your head around
> "unsigned char" versus "char unsigned".
[...]

I'm not aware of anybody here who is unable to get his head around
"unsigned char" vs. "char unsigned". We understand perfectly well
that they're both legal. Many of us simply *dislike* "char unsigned"
and find it counterintuitive, strongly preferring the much more common
"unsigned char".

I will not accuse you of mental retardation for failing to grasp the
difference between being unable to understand something and disliking
something. I do accuse you of extreme rudeness and thoughtlessness,
at least in this one instance. Accusing those who disagree with you
of stupidity is counterproductive, don't you think?

Getting back to the technical issue that was actually being discussed,
consider the following perfectly legal translation unit:

const char unsigned x = 'x';
char const unsigned y = 'y';
char unsigned const z = 'z';

I find all three definitions to be of roughly equally poor style,
because they order the keywords in a manner that's unusual and, IMHO,
counterintuitive. The second is the worst, because it shoves the
"const" keyword into the middle of the type name, but I consider it
only slightly worse than the others. I suspect that most C
programmers would share my opinion.

I understand that you prefer "char unsigned" to "unsigned char", for
whatever reason. I present this example, and my opinion of it, not
because I expect to convince you that I'm right and you're wrong, but
merely to you to understand that those of us who do not share
your opinion are not idiots.

--
Keith Thompson (The_Other_Keith) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Tomás Ó hÉilidhe wrote, On 10/05/08 18:55:
> On May 8, 4:35 am, Jack Klein <jackkl...@spamcop.net> wrote:
>
>> I would have a hard time believing that any people in the world other
>> than you write the ridiculous "char unsigned".

<snip insulting material>

> If you're too mentally retarded to answer that question correctly then
> you'll probably too imcompetent of a programmer to read other people's
> code.

It is not a question about whether people can understand it, it is a
question about what they can understand fastest. The brain is a truly
wonderful pattern matching system, and almost all C programmers brains
are trained to match against the pattern "unsigned char" rather than
"char unsigned". So by going against convention you are forcing people
to stop using the fast method of gaining the information and switch to a
far slower method. When you have to review a few thousand lines of code
written by someone else you will start to appreciate convention, and as
the amount of code goes up you will appreciate it more and more.

Oh, and if you want to discus C then insulting intelligent experienced
and even expert C programmers is not the best way to go about it.
--
Flash Gordon

On May 10, 11:55pm, Keith Thompson <ks...@mib.org> wrote:

> I understand that you prefer "char unsigned" to "unsigned char", for
> whatever reason. I present this example, and my opinion of it, not
> because I expect to convince you that I'm right and you're wrong, but
> merely to you to understand that those of us who do not share
> your opinion are not idiots.


And you're welcome to express that view politely. It's a different
kettle of fish when you say that it's "ridiculous", and keep harking
on about it as did Mr Klein.