Unix Programming - slicing integer into char

Author

slicing integer into char

Ash

2006-08-29, 4:11 am

Hi,

Following code is given by a programmer in a top telecom company to
print all four bytes of integer using char. I am sure that it's not a
good idea; however I hadn't found any solid reason to convince my
point. I came across a line in a site while googling stating that "it's
a bad idea on UNIX". Can someone please suggest a real world example
where this type of work can cause a disaster?

#include <iostream>

using namespace std;

int main ()
{
int val = 32767;
unsigned char c = 0;

for ( int i = 0; i < 4; i++) {
c = val;
cout<< ( int) c<< endl;
val = val >> 8;
}
}

David Schwartz

2006-08-29, 7:59 am

Ash wrote:

> Following code is given by a programmer in a top telecom company to
> print all four bytes of integer using char.

Who says an integer is four bytes? And who says those four bytes
contain consecutive bits of the integer?

> I am sure that it's not a
> good idea; however I hadn't found any solid reason to convince my
> point. I came across a line in a site while googling stating that "it's
> a bad idea on UNIX". Can someone please suggest a real world example
> where this type of work can cause a disaster?
>
> #include <iostream>
>
> using namespace std;
>
> int main ()
> {
> int val = 32767;
> unsigned char c = 0;
>
> for ( int i = 0; i < 4; i++) {
> c = val;
> cout<< ( int) c<< endl;
> val = val >> 8;
> }
> }

The problem with this code is 'c = val;'. That line should be more like
"c=(unsigned char)(val&0xff);'.

If, for example, an 'unsigned char' is 16 bits, this code will break.

The general idea is sound. You should use bit operations instead of
trying to cast pointers or use unions because that kind of code depends
upon assumptions about how types are represented internally. However,
this code ultimately makes that same assumption by assuming a cast from
an 'int' to an 'unsigned char' will result in the 8 least-significant
bits of the integer determining the value of the character.

DS

Chris Friesen

2006-08-29, 7:01 pm

David Schwartz wrote:
> Ash wrote:
>
>
>
> Who says an integer is four bytes? And who says those four bytes
> contain consecutive bits of the integer?

Just playing devil's advocate here...

Are there any common current architectures that run "unix" where an
integer is not four bytes?

I know that Linux currently assumes that ints are always 32 bits, while
longs can vary on 64-bit architectures.

Chris

Bjorn Reese

2006-08-29, 7:01 pm

Chris Friesen wrote:

> Are there any common current architectures that run "unix" where an
> integer is not four bytes?

According to http://www.unix.org/version2/whatsnew/lp64_wp.html

"There have been a few examples of ILP64 systems that have shipped
(Cray and ETA come to mind). These attempts have not had the broad
market base that LP64 systems have had, although they do demonstrate
that it is feasible to complete the implementation of an ILP64
environment."

The ILP64 data model has 64-bits wide integers.

Cray T3C was running a Unix-like operating system (UNICOS/mk) and ETA
some SVR3 variant. Admittedly not the most widely used Unices.

--
mail1dotstofanetdotdk

David Schwartz

2006-08-29, 10:00 pm

Chris Friesen wrote:

> Are there any common current architectures that run "unix" where an
> integer is not four bytes?

Are there today? Not particularly common.

> I know that Linux currently assumes that ints are always 32 bits, while
> longs can vary on 64-bit architectures.

I have certainly used UNIX platforms in the past where an int is 64
bits by default. However, the standard seems to be 32-bit integers and
64-bit longs, at least for now.

If you add appropriate code to abort compilation if the assumptions are
not true, there is nothing wrong with writing code that contains these
assumptions. However, to put in the assumptions gratuituously, where it
is equally easy to not have those assumptions -- there's no excuse for
that.

DS

Sponsored Links