Bit shifting, C/C++ macro conversion

The macros are from the PGP SDK, and are used to extract values from an encoded version number. Here is an excerpt from the PGP sources which sets up the problem:

====
/*
API version:
Top byte is major, next 3 nibbles minor, next 2 bug fix, last nibble reserved:  0xMMmmmrrR
      
example: 1.0.0 = 0x01000000
      
0x01000000 SDK 1.0.0
0x02000000 SDK 1.1.0
0x02000010 SDK 1.1.1
0x03000000 SDK 1.5
0x03000010 SDK 1.5.1
0x03000020 SDK 1.5.2
0x03001000 SDK 1.6
0x03002000 SDK 1.7
0x03002010 SDK 1.7.1
*/

#define kPGPsdkAPIVersion            ( (PGPUInt32)0x03002010 )
#define PGPMajorVersion( v )      ( ( ((PGPUInt32)(v)) & 0xFF000000 ) >> 24 )
#define PGPMinorVersion( v )      ( ( ((PGPUInt32)(v)) & 0x00FFF000 ) >> 16 )
#define PGPRevVersion( v )            ( ( ((PGPUInt32)(v)) & 0x00000FF0 ) >> 4 )

====

The last three are macros to extract the SDK version numbers from kPGPsdkAPIVersion; I've translated them into the following functions (PGPUint32 = Cardinal):

function PGPMajorVersion(const v): PGPUint32;
begin
  result := (PGPUint32(v) and $FF000000) shr 24;
end;

function PGPMinorVersion(const v): PGPUint32;
begin
  result := (PGPUint32(v) and $00FFF000) shr 16;
end;

function PGPRevVersion(const v): PGPUint32;
begin
  result := (PGPUint32(v) and $00000FF0) shr 4;
end;

The problem is that when passed '$03002010' these three functions return 3, 0, and 1, respectively, when I believe they should be returning 1, 7, and 1.

The obvious question is, Have I translated the macros properly? Though I think I understand what the macros are doing, I freely admit to having no experience with bit-shifting.

Can anyone suggest changes to the three functions so they will return the expected results, i.e., 1-7-1 from $03002010, 1-5-2 from $03000020, etc.?
redhornAsked:
Who is Participating?
 
LischkeCommented:
Addtionally, there's no direct way to generally obtain the correct version number from the bit combinations mentioned above. For instance the 7 in 1.7.1 consists of 3 consecutive bits which never appear in the bit field.

Ciao, Mike
0
 
redhornAuthor Commented:
Adjusted points to 150
0
 
LischkeCommented:
I think you problem results from the untyped parameter. Try instead this:

function PGPMajorVersion(const v: PGPUint32): PGPUint32;
begin
  result := (v and $FF000000) shr 24;
end;


Ciao, Mike
0
Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

 
aubsCommented:
Looking at the code I would expect that $03002010 should return:
3, 2 and 1

Which is surely correct:

"Top byte is major, next 3 nibbles minor, next 2 bug fix, last nibble reserved:  0xMMmmmrrR "

Aubs
0
 
LischkeCommented:
I have to make an addition. I think the results you got with your old version are correct. Look at

$03000000

which contains 24 null bits and corresponds therefor to 3 when shifted 24 bits to the right and not 1 as you expect. They say the top byte is major but obviously it doesn't directly correspond to the version number. From the table given it is so that a result of 3 implicitely corresponds to major version 1. This is not a value you can get from bit shifts. You can follow this by comparing the values of the first byte to the major version numbers in the table.

Ciao, Mike
0
 
redhornAuthor Commented:
>Looking at the code I would expect
>that $03002010 should return:
>3, 2 and 1

>Which is surely correct:

>"Top byte is major, next 3 nibbles >minor, next 2 bug fix, last nibble >reserved:  0xMMmmmrrR "

I agree, however the version number is known to be 1.7.1. The translations of the macros have looked right to me from the start, but they have never produced the supposedly correct result.

Based on the comments I have seen I am starting to think that the original macros are incorrect. They are not actually used anywhere in PGP, I've noticed.

0
 
LischkeCommented:
Ah yes, they say the last 3 nibbles are for bug fixes and reserved, so the second macro needs a shift of 12 not 16. I'd say, just ignore them, the table shows nobody ever has used the scheme to encode the version.

Are you going to accept this as answer?

Ciao, Mike
0
 
redhornAuthor Commented:
I had already accepted your previous answer, as a matter of fact. Thank you. "Give it up" is ultimately the answer to my question, but knowing why I should give up helps. ;-)

I think there is some other kind of versioning at work here. I will go back to the documentation to see if there is something else that the output of these macros could refer to. It is true that they aren't used anywhere in PGP itself, but they have been in the sources for years now, and are even referred to in the docs. I must be missing something.
0
 
LischkeCommented:
Good luck and thank you.

Ciao, Mike
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.