Pour obtenir une clé
d'essai remplissez le formulaire ci-dessous
Demandez des tariffs
Nouvelle licence
Renouvellement de licence
--Sélectionnez la devise--
* En cliquant sur ce bouton, vous acceptez notre politique de confidentialité

Free PVS-Studio license for Microsoft MVP specialists
To get the licence for your open-source project, please fill out this form
** En cliquant sur ce bouton, vous acceptez notre politique de confidentialité.

I am interested to try it on the platforms:
** En cliquant sur ce bouton, vous acceptez notre politique de confidentialité.

Message submitted.

Your message has been sent. We will email you at

If you haven't received our response, please do the following:
check your Spam/Junk folder and click the "Not Spam" button for our message.
This way, you won't miss messages from our team in the future.

Problems of 64-bit code in real program…

Problems of 64-bit code in real programs: magic constants

28 Aoû 2009

I would like to tell you about one more 64-bit error we have found in some program. It becomes a good tradition to publish information about interesting and specific programming errors for 64-bit systems and we will try to follow it.

The error described deserves attention because of its simplicity or even ingenuousness. It has been recommended in all the books for many years not to use magic constants in code. Everyone knows about it and mentions it in coding standards. But in practice magic numbers appear in various code sections again and again.

Let's consider an example of CreateFileMapping function's call in some application:

hFileMapping = CreateFileMapping (
    (DWORD) 0,
    (DWORD) (szBufIm),
    (LPCTSTR) &FileShareNameMap[0]);

Right - you have guessed it. The error is in using constant 0xFFFFFFFF. The first argument of CreateFileMapping function may have value INVALID_HANDLE_VALUE defined in the following way:


As a result, INVALID_HANDLE_VALUE does coincide with 0xFFFFFFFF value in a 32-bit system. But in a 64-bit system 0×00000000FFFFFFFF value will be put into CreateFileMapping function and as a result the system will consider the argument incorrect and return the errors' code. The cause is that 0xFFFFFFFF value has UNSIGNED type (unsigned int). 0xFFFFFFFF value does not fit into int type and that's why has unsigned type. It is a subtle point you should pay attention to when performing migration on 64-bit systems. Let's illustrate it by an example:

void foo(void *ptr)
   cout << ptr << endl;
int _tmain(int, _TCHAR *[])
   cout << "-1\t\t";
   foo((void *)-1);
   cout << "0xFFFFFFFF\t";
   foo((void *)0xFFFFFFFF);

The result in the 32-bit version of the program:

-1              FFFFFFFF

The result in the 64-bit version of the program:

-1              FFFFFFFFFFFFFFFF
0xFFFFFFFF      00000000FFFFFFFF

You will ask how one can remember this all and how one can be sure that the old code does not contain such traps. As usual here you are an ad-answer - use a specialized system of static analysis Viva64 included into PVS-Studio.

Comments (0)

Next comments
Unicorn with delicious cookie
Nous utilisons des cookies pour améliorer votre expérience de navigation. En savoir plus