the magic of MAGIC numbers

Have you ever seen them?

The cute little #defines and consts that have weird looking values like 0x81772012 or 0x49122035, used allover the code...
the purpose which is known to only to their author ???

If you ever had interest in encrypting you're probably acquainted with them
(Berkely DB has a full load of them! )


i was wondering how people invent them!
is it like "hmm let see ... square of 0x1231 minus 0x121909 plus 0x93abde XOR 0x132958 add one more AND VOILA !! thats the number that solves my problems!!! "

and also if you have some interesting and working code loaded with them share it !
heres some :

Code:

---

//Berkely DB hashing algorithms (one of the best i've ever seen)

#define        DCHARHASH(h, c)        ((h) = 0x63c63cd9*(h) + 0x9c39c33d + (c))

#define UINT8 unsigned char


UINT Hashfunc1(const void *key,UINT len)
{
        const UINT8 *e, *k;
        UINT h;
        UINT8 c;

        k = key;
        e = k + len;
        for (h = 0; k != e;) {
                c = *k++;
                if (!c && k > e)
                        break;
                DCHARHASH(h, c);
        }
        return h;
}


//////Better
unsigned int  Hashfunc2(const void *key,UINT len)
{
        const unsgined char *e, *k;
        unsigned int h;
        k = key;
        e = k + len;
        for (h = 0; k < e; ++k) {
                h *= 16777619; //what is that MAGIC ?!?!?!
                h ^= *k;
        }
        return h;
}

---

Code:

---

//author :Praveena <[email protected]>

//descr: some encrypting scheme i found
//the folowing code is used for generating
// key seeds
#define cypher 8
#define CYPHER_SZ (8*sizeof(int32_t))

typedef char int8_t;
typedef short int16_t;
typedef int int32_t;
typedef __int64 int64_t;

typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef unsigned int uint32_t;
typedef unsigned __int64 uint64_t;

void modseed(int32_t seed[cypher]) {
        int x;
        for(x=1;x<cypher;x++)
                seed[x]=seed[x]*0x81772012+seed[x]+0x49122035+seed[x+1];
        for(x=1;x<cypher;x++)
                seed[0] ^= seed[x];
}
int seedsum(int32_t seed[cypher]) {
        int n,x;
       
        n=0x80379251;
        for(x=0;x<cypher;x++)
                n=n^seed[x];
               
        return ((n>>24)^((n>>16)&255)^((n>>8)&255)^(n&255));
}
void seed_gen(char *pwd,int32_t seed[cypher]) {
    char *pp = pwd;
        memset((void*)seed,0,CYPHER_SZ);
    modseed(seed);
    while((*pp)){
        modseed(seed);
        seed[0]=seed[0]+(*pp);
        modseed(seed);
        pp++;
    }
}
// and encoding
int encode(char *buf,char *password) {
  int ret = 0;
  char *pstr = buf;
  int seed[cypher];
  seed_gen(password,seed);
  while(*pstr) {
      modseed(seed);
      *pstr ^= (char)(seedsum(seed));
      pstr++;
  }
  *pstr = '\0';
  return 1;
}

---

Those are hexadecimal numbers, base 16, used in memory addresses.

0xC000

>>Those are hexadecimal numbers, base 16, used in memory
>>addresses

hmm ...
the fact that they are hex doesn't mean that the author use them for address arithmetics ...
they could be-bit masks (even more often)

nobody use constants for memory addressing
you never assign constant to a pointer you allways use
[base address + offset]

Quote:

---

The cute little #defines and consts that have weird looking values like 0x81772012 or 0x49122035, used allover the code...
the purpose which is known to only to their author ???

---

Yes. That is just why people use constants and #defines, to make the code readable and understandable. Usually the constant or #define tells you what the value represents. It often requires more information on how the value was derived.

>i was wondering how people invent them!

Depends on the application.

that was not what i ment

people use #defines for many things
i was fascinated by some code (like Berkely's DB hashing algorithm) in which those numbers make great things

look at the Berkely DB hashing algorithm!

Code:

---

/*
 * Fowler/Noll/Vo hash
 *
 * The basis of the hash algorithm was taken from an idea sent by email to the
 * IEEE Posix P1003.2 mailing list from Phong Vo ([email protected]) and
 * Glenn Fowler ([email protected]).  Landon Curt Noll ([email protected])
 * later improved on their algorithm.
 *
 * The magic is in the interesting relationship between the special prime
 * 16777619 (2^24 + 403) and 2^32 and 2^8.
 *
 * This hash produces the fewest collisions of any function that we've seen so
 * far, and works well on both numbers and strings.
 *
 * PUBLIC: u_int32_t __ham_func5 __P((DB *, const void *, u_int32_t));
 */
u_int32_t
__ham_func5(dbp, key, len)
        DB *dbp;
        const void *key;
        u_int32_t len;
{
        const u_int8_t *k, *e;
        u_int32_t h;

        if (dbp != NULL)
                COMPQUIET(dbp, NULL);

        k = key;
        e = k + len;
        for (h = 0; k < e; ++k) {
                h *= 16777619;
                h ^= *k;
        }
        return (h);
}

---

>The cute little #defines and consts that have weird looking
>values like 0x81772012 or 0x49122035, used allover the code...
>the purpose which is known to only to their author ???
The purpose is usually well known, and not half as interesting as how the magic number was thought up. :) For Example, the superblock tag of the BSD sys/fs/ufs_fs.h is

#define FS_MAGIC 0x011954

It seems pretty cryptic until you learn that the number is actually the birthday of the author, Kirk McKusick. It gets even stranger, some magic numbers are chosen because they were easily recognized opcodes in the early days of programming.

-Prelude

Prelude, you know too damn much...
:)

!!! :)
birthday huh!

so the machine says Happy Birthday To You :)