Questions about "alignment" in memory

[J. Campbell]

I posted a question some time back about accessing a char array as an
array of words. In order not to overrun the char array, I padded it
with enough 0x00 bytes to ensure that when accessed as words I
wouldn't overrun the array. I was told that this is dangerous and
that there could be alignment problems if, for example, I wanted to
access the char array elements from non-even multiples of sizeof(int).
For example, if I had the array:

char a[10];

and I wanted to access the 8 bytes (a[2], a[3],..., a[8], a[9]) as the
array:

int b[2];

where (b[0] contains the data in a[2] to a[5], and b[1] contains a[6]
to a[9])

I understand the alignment issue in this example. My question
is...can I turn this problem on its head...for example, create an
empty array of ints, then access this memory space as a char?

Here's what I'm talking about:
unsigned int* a_words;
char* a_bytes;

fstream in("myfile.dat" , ios::in | ios::binary | ios::ate);
int filesize_bytes = in.tellg();
int filesize_words = filesize_bytes / sizeof(int) + ((filesize_byte s %
sizeof(int)) > 0); // add 1 if there is a remander...

a_words = new unsigned int[filesize_words];
a_bytes = reinterpret_cas t<char*>(a_word s);

in.seekg(2, ios::beg); //note...out of (word) alignment...sta rts on
3rd byte
in.read(a_bytes , filesize_bytes-3);
in.close();

at which point the file is in memory and can be accessed as bytes (by
indexing a_bytes[0 to filesize_bytes]) or as words (by indexing
a_words[0 to filesize_words].

This seems to work fine. Additionally, it shouldn't suffer potential
alignment problems since the array is defined to align with words, and
word addresses should be accessable to a byte address, even if the
converse of this is not true.

I can see that there will be compatibility problems with this system
if ported to a system where CHAR_BIT != 8. However, I don't care
about these systems. If I'm only doing logical operators on the bits
in the file, I don't even see any endian issues with doing this.

Thanks for the slap-in-the-face I'm sure I'll get for performing such
blastphomous operations in c++. Seriously, does this treatment
circumvent potential alignment issues?

[Default User]

"David B. Held" wrote:

After reading Default User's post, I realized I should have added
the caveat that it will probably work on 99% of the compilers
and systems out there *but in a generally non-portable way*.
That means that since you're reading raw bytes into an array
from a file, and assuming a certain byte order for int, the code
obviously won't work on a platform that has a different byte order.
But usually, people who do stuff like this aren't interested in
portability in the first place.

Byte order is a big problem for me, because my code has to work on
Windows for desktop testing, then to the target hardware, which has a
different endianess. My methods (bitwise ops) were compatible to both
without change. You'll have an easier time finding platforms with
CHAR_BIT == 8 and 32-bit integral types.

Once you devise the packing and unpacking routines for the data words,
then all you need to deal with is the unsigned char array.


Brian Rodenborn

[Samuel Barber]

ma**********@ya hoo.com (J. Campbell) wrote in message news:<b9******* *************** ****@posting.go ogle.com>...

I understand the alignment issue in this example. My question
is...can I turn this problem on its head...for example, create an
empty array of ints, then access this memory space as a char?
Sure.
I can see that there will be compatibility problems with this system
if ported to a system where CHAR_BIT != 8. However, I don't care
about these systems. If I'm only doing logical operators on the bits
in the file, I don't even see any endian issues with doing this.

If you access the array as int, you will be endian-specific. Whether
you use arithmetic or logic operations makes no difference.

Sam

[J. Campbell]

Default User wrote in message news:<3F******* ********@boeing .com.invalid>.. .

Here's a way from my personal library:

unsigned int CreateDataWord (unsigned char data[4])
{
unsigned int dataword = 0;

for (int i = 0; i < 4; i++)
{
dataword |= data[i] << (3-i) * 8;
}
return dataword;
}
Note that this uses unsigned char for the buffer, which is guaranteed to
be safe, requires CHAR_BIT == 8, and is predicated on 32-bit int, so it
has its own nonportabilitie s.

Brian Rodenborn

Thanks for the input, Brian. Regarding your function
CreateDataWord. ..I just want to point out that if you just want to
pack a char buffer into ints, you can do this portabally while making
no assumptions of the system bit size, or the size of CHAR_BIT.
However, you actually need two functions...dep ending on how you want
to pack your word...the function you show packs the word Little
Endian. Here is compilable code that uses 2 portable versions of your
function.

#include <iostream>

using namespace std;

void wait();
unsigned int makeBE(unsigned char a[]);
unsigned int makeLE(unsigned char a[]);
bool endian_check();

int main(){
int ws = sizeof(int);
cout << "This is a " << ws * CHAR_BIT << "-bit system\n"
<< "Bytes are " << CHAR_BIT << "-bits\n"
<< "Words are " << ws << " bytes\n\n"
<< "Checking system endianness...Sy stem is ";

if(endian_check ()) cout << "Little Endian (Intel)\n\n";
else cout << "Big Endian (Motorola)\n\n" ;

unsigned char data[ws]; // Make a 1-word char array and fill it
for(int i = 0; i < ws; ++i) data[i] = 0x41 + i;

cout << "The " << ws << " byte sequence \"";
for(int i = 0; i < ws; ++i) cout << data[i];
cout << "\" (Ascii)\n"
<< "is translated to a " << ws
<< " byte integer word (hex) as:\n\n" << hex;
cout << "Big Endian(Motorola ): " << makeBE(data) << endl;
cout << "Little Endian(Intel): " << makeLE(data) << endl << endl;
wait();
return 0;
}

unsigned int makeBE (unsigned char data[sizeof(int)]){
unsigned int dataword = 0;

for (int i = 0; i < sizeof(int); i++)
dataword |= (data[i] << (i * CHAR_BIT));
return dataword;
}

unsigned int makeLE (unsigned char data[sizeof(int)]){
unsigned int dataword = 0;
int index = 0;

for (int i = sizeof(int); i > 0; )
dataword |= data[index++] << --i * CHAR_BIT;
return dataword;
}

bool endian_check(){
unsigned int word = 0x1;
unsigned char* byte = reinterpret_cas t<unsigned char*>(&word);
return (byte[0]); // returns 1 if LE, 0 if BE
}

void wait(){
cout<<"<Enter> to continue..";
string z; getline(cin,z);
}

[WW]

Default User wrote:

WW wrote:

Default User wrote:

WW wrote:

Yes you can, but only with char being the "other" thing. Another
solution is to define a union, with a char and an int array inside.
This is not guaranteed. It is implementation-defined behavior if the
value of a member of a union object is used when the most recent
store to the object was to a different member, other than structs
sharing a common initial sequence.
yep. But we are talking about a char and an int array so far.

Right, which don't come under the exemption. If I got the OP's problem
right, he had a buffer of char that he wanted to convert into a series
of ints. Using unions to do so would be implementation-defined
behavior (if I'm reading the standard correctly).

Yeah, you do. Emerican Netiveness. :-)
Here's a way from my personal library:

unsigned int CreateDataWord (unsigned char data[4])
{
unsigned int dataword = 0;

for (int i = 0; i < 4; i++)
{
dataword |= data[i] << (3-i) * 8;
}
return dataword;
}

Note that this uses unsigned char for the buffer, which is guaranteed
to be safe, requires CHAR_BIT == 8, and is predicated on 32-bit int,
so it has its own nonportabilitie s.

Yepp... But if you did write long int, then it would be fully portable
IIRC.

--
WW aka Attila

[Default User]

WW wrote:

Note that this uses unsigned char for the buffer, which is guaranteed
to be safe, requires CHAR_BIT == 8, and is predicated on 32-bit int,
so it has its own nonportabilitie s.

Yepp... But if you did write long int, then it would be fully portable
IIRC.

Probably should have been long. My original code used our own local
guaranteed sized type, UINT_32, which is very nonportable.

Brian Rodenborn