C standard question?

[jan.chludzinski]

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

 

[Flash Gordon]

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:


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.

 

[Tomás Ó hÉilidhe]

        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;

 

[Chris H]

In message

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.

 

[Tomás Ó hÉilidhe]

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.

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.

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

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.

 

[Tomás Ó hÉilidhe]

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.

 

[Tomás Ó hÉilidhe]

you'll

typo: you're

 

[Chris H]

Chris H said:


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?

 

[lawrence.jones]

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

 

[Chris H]

Chris H said:


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

 

[Tomás Ó hÉilidhe]

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.

 

[Richard Tobin]

I'm here to converse about C

The evidence suggests otherwise.

-- Richard

 

[Keith Thompson]

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 help you to understand that those of us who do not share
your opinion are not idiots.

 

[Flash Gordon]

Tomás Ó hÉilidhe wrote, On 10/05/08 18:55:

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.

 

[Tomás Ó hÉilidhe]

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

 

[Keith Thompson]

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.

"Ridiculous" is a matter of opinion. Personally, I agree that using
"char unsigned" rather than "unsigned char" is ridiculous.

Your reaction was extremely rude and unjustified by the provocation.

 

[Joachim Schmitz]

"Ridiculous" is a matter of opinion. Personally, I agree that using
"char unsigned" rather than "unsigned char" is ridiculous.

Your reaction was extremely rude and unjustified by the provocation.

Well, calling someone 'riduculous' shurely is offensive and far beond
voicing an opinion, so the reaction was by no means unjustified, but IMHO
too strong.
Being atacked by a knife doesn't justify launching a rocket...

Bye, Jojo

 

[Chris H]

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.

Thanks.

I have only eve seen one compiler that did it that way and they changed
to the unsigned char over a decade ago. I did scan through the standard
but missed the clause.

 

[Chris H]

In message

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.

I think you have just got yourself killfiled by the leading experts (I
hate that word on this group. They have many years experience of
the language and some are on various C panels (ISO and others)

So you are unlikely to be able to discuss C with anyone on this NG who
knows what they are talking about until you change your identity and
attitude.

 

[Spiros Bousbouras]

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

One Frederick Gotham who used to post here a lot
preferred "char unsigned", someone called it
ridiculous, then Frederick called that person fascist
and it went on from there quite unpleasantly for a
while. Did you miss all that ? Is Tomás Ó hÉilidhe
the same person as Frederick Gotham ?

Anyway I believe that "char unsigned" is harmless
and does not warrant an inflammatory and potentially
offensive comment as "ridiculous". Especially if it's
the only comment in the post.