Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > C standard question?

Reply
Thread Tools

C standard question?

 
 
jan.chludzinski@gmail.com
Guest
Posts: n/a
 
      05-07-2008
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 ] << | c[ 0 ];
fprintf( stderr, "ui = %x\n", ui );
}

and got:

> ui = ffffffff


But validation through compilation is a dangerous thing!

---jski
 
Reply With Quote
 
 
 
 
Flash Gordon
Guest
Posts: n/a
 
      05-07-2008
http://www.velocityreviews.com/forums/(E-Mail Removed) 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 ] << | 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
 
Reply With Quote
 
 
 
 
Tomás Ó hÉilidhe
Guest
Posts: n/a
 
      05-07-2008
On May 7, 8:20*pm, Eric Sosman <(E-Mail Removed)> 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;
 
Reply With Quote
 
Chris H
Guest
Posts: n/a
 
      05-10-2008
In message
<(E-Mail Removed)>,
Tomás Ó hÉilidhe <(E-Mail Removed)> writes
>On May 7, 8:20*pm, Eric Sosman <(E-Mail Removed)> 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 /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



 
Reply With Quote
 
Tomás Ó hÉilidhe
Guest
Posts: n/a
 
      05-10-2008
On May 8, 4:44*am, Jack Klein <(E-Mail Removed)> 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.
 
Reply With Quote
 
Tomás Ó hÉilidhe
Guest
Posts: n/a
 
      05-10-2008
On May 8, 4:35*am, Jack Klein <(E-Mail Removed)> 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.
 
Reply With Quote
 
Tomás Ó hÉilidhe
Guest
Posts: n/a
 
      05-10-2008
On May 10, 6:55*pm, Tomás Ó hÉilidhe <(E-Mail Removed)> wrote:

> you'll


typo: you're
 
Reply With Quote
 
Chris H
Guest
Posts: n/a
 
      05-10-2008
In message <(E-Mail Removed)>, Richard Heathfield
<(E-Mail Removed)> writes
>Chris H said:
>
>> In message
>> <(E-Mail Removed)>,
>> Tomás Ó hÉilidhe <(E-Mail Removed)> 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 /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



 
Reply With Quote
 
lawrence.jones@siemens.com
Guest
Posts: n/a
 
      05-10-2008
Chris H <(E-Mail Removed)> 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
 
Reply With Quote
 
Chris H
Guest
Posts: n/a
 
      05-10-2008
In message <(E-Mail Removed)>, Richard Heathfield
<(E-Mail Removed)> writes
>Chris H said:
>
>> In message <(E-Mail Removed)>, Richard Heathfield
>> <(E-Mail Removed)> writes
>>>Chris H said:
>>>
>>>> In message
>>>> <(E-Mail Removed)>,
>>>> Tomás Ó hÉilidhe <(E-Mail Removed)> 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 /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
standard libraries don't behave like standard 'libraries' Sriram Srinivasan Python 13 11-12-2009 06:05 PM
What are the standard network functions provided in standard C? disappearedng@gmail.com C Programming 5 06-10-2008 08:57 PM
How to redirect a "system" standard output and standard error to avariable (Linux) Venks Ruby 5 12-06-2007 12:21 AM
add pexpect to the standard library, standard "install" mechanism. funkyj Python 5 01-20-2006 08:35 PM
How standard is the standard library? steve.leach Python 1 04-18-2005 04:07 PM



Advertisments