bitwise operation without the use of a bigint class?

Question

0.00/5 (No votes)

See more:

Hello.

I know I have asked a simular question before, but I am still facing problems with it, and I have managed to condense my problem so that, hopefully, it is a little better to understand?

I have the following function/code:

private void button1_Click(object sender, EventArgs e)
        {

            // Raw license, fixed bytes compiled from productID, product Version, License Data, expiery and 2-3 random bytes.
            byte[] rawLicense = {0x00, 0x00, 0xA3, 0xE1};


            int  i = rawLicense[3] + (rawLicense[2] << 8) + (rawLicense[1] << 16) + (rawLicense[0] << 24);

        }

This takes the hex value 00 00 A3 E1 and uses bitshifting to form the int representation of that hex value, which is: 41953

Now, how can I edit the above function to allow me to work with a byte array of a bigger length, that would produce an int like the one below:

45434-59685-45565-59685-56923-49565

I would prefer not to use a bigint class, and I have seen code simular to the above that does this, producing a string that represents a larger int, or at least a string of digits like the above, and, of course, a method to reverse the string into a byte array.

Thank you very much,
Kind Regards,
Stephen

Posted 28-Jul-11 6:30am

stephen.darling

Add a Solution

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Alexandru Ghiondea · Answer 1 · 2011-07-28T06:44:00

Solution 1

Why don't you encapsulate the code in the button above into a method:

C#

int GetIntFromByteArr(byte[] rawLicense)
{
  int  i = rawLicense[3] + (rawLicense[2] << 8) + (rawLicense[1] << 16)     + (rawLicense[0] << 24);
  return j;
}

And call it multiple times?

C#

int el1 = GetIntFromByteArr(new byte[]{0x00, 0x00, 0xA3, 0xE1});
int el2 = GetIntFromByteArr(new byte[]{0x00, 0x10, 0x00, 0xB1});
// ....

Then you would just concatenate those integers.

You could of course optimize this in such a way that you are passing the array to the method and the indexes that represent the start/end position to convert.

Hope this helps,
Alex

Posted 28-Jul-11 6:44am

Alexandru Ghiondea

Comments

stephen.darling 28-Jul-11 13:00pm

Hi.
That does not seem to work.

for example, please consider:

A3,E1 = 41953
A5,B6 = 42422

if I concatanate these I have 4195342422

But A3,E1,A5,B6 = 2749474230

Thank you,
Stephen

Alexandru Ghiondea 28-Jul-11 13:11pm

My understanding was that you wanted to get to this type of string from your byte array:

45434-59685-45565-59685-56923-49565

Could you walk me through an example?

Alex

stephen.darling 28-Jul-11 13:19pm

OK,

Lets say I create a byte array in hex of the following:

C7854ED1587CB87D

This would be represented as the following string of digits:

-4069760027219675011

so uint would be no good, but i do not want to use a bigint class

Does this make sense?

Steve

Amund Gjersøe 28-Jul-11 17:41pm

First, that is a big number. Since you write them separated, it would seem like it is a array of numbers rather than one big. But since that has been suggested I would suggest an other idea: Try doing it mathematically.
Like:
You have in hex '87D',
8 = 16^2 * 8 = 2048, write 2 to the string and keep the remaining 48.
7 = 16*7 = 112, 112 + 48 = 160, write 1 to the string and keep the remaining 60.
D = 13, 13 + 60 = 73, write 73 to the string.

You now have converted 0x87D to 2173.

Don't think 16^50 will compute without some rounding-off.

Alexandru Ghiondea 28-Jul-11 18:16pm

How would you go back to the original hex string from the number?

Or this is just a way to "check-sum" the original hex string?

Alexandru Ghiondea 28-Jul-11 13:21pm

So you want to convert the hex string into its the decimal representation?

Alex

Alexandru Ghiondea · Answer 2 · 2011-07-28T08:06:00

Solution 2

All right, let's try this again :)

Try this piece of code:

C#

class Program
{
    static void Main(string[] args)
    {
        byte[] rawLicense = { 0x00, 0x00, 0xA3, 0xE1, 0xA5, 0xB6 };

        int shift = 0;
        long result = 0;
        for (int i = rawLicense.Length - 1; i >=0 ; i--, shift += 8)
        {
            long value = (long)rawLicense[i] << shift;
            result += value;
        }

        Console.WriteLine(result);
    }
}

You are still limited to what a long can hold without overflowing though so be careful about that.

Posted 28-Jul-11 8:06am

Alexandru Ghiondea

Comments

stephen.darling 28-Jul-11 14:31pm

Hi.
Thank you, you now know what I mean.
However, in my real example, I will be using 50+ bytes, instead of the 6 in the above example.

Therefore long is no good, as my string should be encoded like...
00000-00000-00000-00000-00000-00000-0000 etc, over60 digits long

Does this help :)
Steve

Alexandru Ghiondea 28-Jul-11 14:36pm

Well - this won't work for 50+ digits :|. This is because the long type cannot hold a value bigger than 2^64.

This is the reason why the BigInt type was created - so you can have an arbitrarily large number. What is the reason why BigInt is not acceptable?

But now I go back to my first solution - Why don't you want to generate smaller numbers - basically partitioning your number into chunks? Why is that not an acceptable solution?

Alex