Could someone explain this code for me please...

**Dae** · 06-24-2005

I'm not sure what I'm trying to accomplish, hell I dont even know how true encryption is suppose to work. I'm going to put things on halt until I get some concepts to work with now that I understand bitfields got JoshR's union idea down pact. Gonna go look up some tutorials.

I uses JoshR's example to show how the bitfield struct in the union could be used to mix around the binary of the other methods in the union. No idea for what purpose, honestly.

Code:

#include <iostream>
#include <cstdio>

using namespace std;

struct char4 {
        unsigned int a:2;
        unsigned int b:2;
        unsigned int c:2;
        unsigned int d:2;
};

union TEST {
        char A[]; // the data to binary edit
        char4 bits[]; // the bitfields used to do so
};

int main() {
    TEST ch;
    strcpy(ch.A, "This is a string.\0");

    cout << "Size of TEST:  (unable to determine atm)" << endl;;
    cout << "String A:   " << strlen(ch.A) << endl;

    // change every second bit, if its 1 it becomes 0, or visa-versa
    for( int x = 0; x < strlen(ch.A); ++x ) {
       ch.bits[x].a = ch.bits[x].a ^ (1 << 1);
       ch.bits[x].b = ch.bits[x].b ^ (1 << 1);
       ch.bits[x].c = ch.bits[x].c ^ (1 << 1);
       ch.bits[x].d = ch.bits[x].d ^ (1 << 1);
    }

    cout << "String A:   " << ch.A << endl;

    // return the string back to the way it was
    for( int x = 0; x < strlen(ch.A); ++x ) {
       ch.bits[x].a = ch.bits[x].a ^ (1 << 1);
       ch.bits[x].b = ch.bits[x].b ^ (1 << 1);
       ch.bits[x].c = ch.bits[x].c ^ (1 << 1);
       ch.bits[x].d = ch.bits[x].d ^ (1 << 1);
    }

    cout << "String A:   " << ch.A << endl;
    cin.get();
}

A std::string wouldnt work because of errors, so I used a char string. If you had some class that imported data and assigned it to some space just like where that char string is.. Might work, might not work, definetly needs expansion but in any case thats 1 thing I was trying to do.. but dont care to spend anymore time mixing the binary around for fun because I know this encryption could be more efficient if I knew more concepts.

Ah apparently using XOR you could encrypt it using anything, so I guess this implement might not be so good.. Got anymore ideas JoshR? I didnt know what you were talking about at the beginning of this thread because I had never seen this before, but I remember at the beginning of the thread you were on about a union and XOR and thats finally where I am

**JoshR** · 06-24-2005

Strings should work, im working on an algorithm right now that i call the stairway method where it shifts the blocks of 8 bits around an array (char* or string) in a stairway fassion, then later i will do some XOR and other bit tricks. I am working on a template that allows either string or char* and decides how to calculate the size accordingly. Ill post some code once i make significant progress, just working on pseudocode right now.

btw

Code:

for( int x = 0; x < strlen(ch.A); ++x ) {

you should calculate the string lenght ( strlen(ch.A) ) outside of the loop because it calls the function that has to use an algorithm and calculate it each time it is looped so better to do it once.

**JoshR** · 06-24-2005

lol its gonna take me a while, i like to work out the details on paper first, like the theory behind it etc... this is all i have so far:

Code:

#include <iostream>
using namespace std;

///////////////////////////////////////////
typedef unsigned int CHAR32;
///////////////////////////////////////////
struct BITBLOCKS {
   unsigned int    one:8;
   unsigned int    two:8;
   unsigned int  three:8;
   unsigned int   four:8;
};
///////////////////////////////////////////
typedef union {
   unsigned int  value;
   BITBLOCKS      bits;
} BITUNION;
///////////////////////////////////////////

int main() {

   cin.get();
   return 0;
}

**Hunter2** · 06-24-2005

>>A std::string wouldnt work because of errors
While searching for a reference I saw recently explaining in detail why you can't use complex classes inside unions, I stumbled across this:

Unions are not always portable, due to the way different processors store bytes in memory. Our version of itoh(), for instance, runs correctly on IntelÆ processors, but displays the bytes in reverse order on SPARCÆ-based workstations.

So, yeah, looks like it'd take a bit more work to get the direct bit-access to work in a foolproof manner (probably can solve this using compiler-defined macros that will somehow identify what order the bits are stored in).

*EDIT: JoshR, just so you know, since your bitfields are all 8 bits you might as well use unsigned char.

**JoshR** · 06-25-2005

Ya i just used the same types i saw before, good idea for chars, wont waste bytes.

Hmm thats interesting about unions...Brings a lot of thoughts to mind.

**Dae** · 06-25-2005

Originally Posted by JoshR

Ya i just used the same types i saw before, good idea for chars, wont waste bytes.

Wont waste bytes either way, the reason he suggested to use a char is so you dont call a bitfield operation (takes more time than using a char) and you cant retrieve the memory address of the bitfields, with a char you can.

Hmm thats interesting about unions...Brings a lot of thoughts to mind.

Yeah what Hunter said is why I cant use a string instead of a char*, its a complex class, so it gives you errors about having a constructor and deconstructor and such when you use a string.

Im now just making a program to import text files and encrypt/decrypt them, because it was more fun seeing the effects that way

. Throw in a XOR and a complement~ in there, but still having a trouble finding something to encrypt thats based on the file (ie. bytes in the file, length of the file title, etc.) but those values can change so that wouldnt decrypt well.

It says the best way to encrypt something is to compress it first, agh not sure how to do large scale import file compressions so off to google.

**Dae** · 06-25-2005

Originally Posted by JoshR

Code:

for( int x = 0; x < strlen(ch.A); ++x ) {

you should calculate the string lenght ( strlen(ch.A) ) outside of the loop because it calls the function that has to use an algorithm and calculate it each time it is looped so better to do it once.

Oh, thanks for pointing that out!

**quzah** · 06-25-2005

Originally Posted by Hunter2

I stumbled across this:

Unions are not always portable, due to the way different processors store bytes in memory. Our version of itoh(), for instance, runs correctly on IntelÆ processors, but displays the bytes in reverse order on SPARCÆ-based workstations.

So, yeah, looks like it'd take a bit more work to get the direct bit-access to work in a foolproof manner (probably can solve this using compiler-defined macros that will somehow identify what order the bits are stored in).

Actually you need to not quote stupid people. This has nothing to do with unions at all. Unions are portable. The person you quoted is an idiot, and doesn't understand that it has to do with integer byte ordering, and nothing at all to do with unions. They may as well have stated "classes are not completely portable" or "structures are not completely portable". The problem has nothing to do with unions. It's the byte order of the integer itself.

You should point whoever you quoted over to some place like here so they get a better clue as to what they're talking about.

The reason it seems like a problem with the union, is because the union specificly shows them the individual bytes because of the way they've got it set up, so they can see the real issue: byte ordering.

Quzah.

**Hunter2** · 06-25-2005

Oops, yes, it didn't occur to me to point out that the problem isn't with unions themselves. But that particular quote pretty much summed up what I've been trying to say in several of my previous posts - that this particular use of unions isn't necessarily portable - which I had no confirmation for prior to this (and, I was working with only a fuzzy idea of what *might* go wrong, I wasn't sure specifically what). Thanks for the clarification.

**JoshR** · 06-25-2005

What could be used to determine if the system uses big endian or little endian?

**JoshR** · 06-25-2005

could you do this:

Code:

#include <iostream>
using namespace std;

///////////////////////////////////////////
typedef unsigned int CHAR32;
///////////////////////////////////////////
struct BITBLOCKSB {
   unsigned char    one;
   unsigned char    two;
   unsigned char  three;
   unsigned char   four;
};
///////////////////////////////////////////
struct BITBLOCKSL {
   unsigned char   four;
   unsigned char  three;
   unsigned char    two;
   unsigned char    one;
};
///////////////////////////////////////////
typedef union {
   unsigned int    value;
   BITBLOCKSB       bits;
} BITUNIONB;
///////////////////////////////////////////
typedef union {
   unsigned int    value;
   BITBLOCKSL       bits;
} BITUNIONL;
///////////////////////////////////////////
bool BIGENDIAN() {
   short int bit = 1;
   char* byte = (char*) &bit;
   return(byte[0] ? true : false);
}
///////////////////////////////////////////
#define BIGENDIAN BIGENDIAN()
///////////////////////////////////////////

int main() {
   if (BIGENDIAN)
      BITUNIONB bitUnion;
   else
      BITUNIONL bitUnion;

   cin.get();
   return 0;
}

**JoshR** · 06-25-2005

Instead could i possibly use preprocessor directives? im not the best with them, dont use them that much, but could i do this instead?

Code:

#include <iostream>
using namespace std;

/////////////////////////////////////////////////
typedef unsigned int CHAR32;
//-----------------------------------------------
// Breaks up 32 bits into blocks of 8 bits
// BITBLOCKSB for Big-Endian
// BITBLOCKSL for Little-Endian
//-----------------------------------------------
struct BITBLOCKSB {
   unsigned char    one;
   unsigned char    two;
   unsigned char  three;
   unsigned char   four;
};

struct BITBLOCKSL {
   unsigned char   four;
   unsigned char  three;
   unsigned char    two;
   unsigned char    one;
};
//-----------------------------------------------
// Allows access to the bit blocks
// BITUNIONB for Big-Endian
// BITUNIONL for Little-Endian
//-----------------------------------------------
typedef union {
   CHAR32      value;
   BITBLOCKSB   bits;
} BITUNIONB;

typedef union {
   CHAR32      value;
   BITBLOCKSL   bits;
} BITUNIONL;
//-----------------------------------------------
// Current PC endian type
//-----------------------------------------------
bool ENDIAN() {
   short int bit = 1;
   char* byte = (char*) &bit;
   return (byte[0] ? true : false);
}
//-----------------------------------------------
const bool BIGENDIAN = ENDIAN();
//-----------------------------------------------   
#if (BIGENDIAN)
   #define BITUNION BITUNIONB
#else 
   #define BITUNION BITUNIONL
#endif
/////////////////////////////////////////////////

int main() {
   BITUNION bitUnion;
   bitUnion.value = 254;
   cout << (int)bitUnion.bits.one << " " << (int)bitUnion.bits.two << " " 
      << (int)bitUnion.bits.three << " " << (int)bitUnion.bits.four;
      
   cout << endl << "Big Endian? " << (BIGENDIAN ? " Yes" : " No") << endl;
   cin.get();
   return 0;
}

**Salem** · 06-26-2005

This thread has gotten too large to even read what everyone's been saying, and somewhere along the line the topic changed from bitfields to endianess.

I suggest you ask your current specific question in a new thread, so we can all see once again what the real issues are.