Magic number (programming)
From Free net encyclopedia
- For other uses of the term, see magic number.
In computer programming, a magic number is a special constant used for some specific purpose. It is called magic because it is hardcoded in and its value or presence is inexplicable without some additional knowledge.
Magic numbers are often chosen based on (among other factors):
- ASCII code (most common)
- Representation in hexadecimal (e.g. decimal 305419896 equals
0x12345678
) - Sometimes hexspeak is used
Contents |
Magic numbers in files
An early convention in the Unix operating system was that (binary) files started with two bytes containing a "magic number" identifying the type of the file. These were originally used by the Unix linker and loader. The concept has been expanded on over time, and is now in current use by many other programs across many operating systems. It is a form of in-band signaling.
In a quick hack, the very earliest magic numbers were PDP-11 branch instructions. The concept of magic numbers can be generalized to all files, since any un-encoded binary data is essentially a number; most file formats can thus be identified by some signature that occurs somewhere in the file. Detecting such sequences is therefore an effective way of distinguishing between file formats - and can often yield further information at the same time.
Some examples:
- Compiled Java class files (bytecode) start with
0xCAFEBABE
on big-endian systems. - GIF image files have the ASCII code for 'GIF89a' (
0x474946383961
) or 'GIF87a' (0x474946383761
) - JPEG image files begin with
0xFFD8FF
, and JPEG/JFIF files contain the ASCII code for 'JFIF' (0x4A464946
) or JPEG/EXIF files contain the ASCII code for 'Exif' (0x45786966
) beginning at byte 6 in the file, followed by more metadata about the file. - PNG image files begin with an 8-byte signature which identifies the file as a PNG file and allows immediate detection of some common file-transfer problems:
\211 P N G \r \n \032 \n
(0x89504e470d0a1a0a
) - Standard MIDI music files have the ASCII code for 'MThd' (
0x4D546864
) followed by more metadata about the file. - Unix script files usually start with a shebang, '#!' (
0x2321
, or0x2123
on little-endian processors) followed by the path to an interpreter. - Old MS-DOS .exe files and the newer Microsoft Windows PE (Portable Executable) .exe files start with the ASCII string 'MZ' (
0x4D5A
), the initials of the designer of the file format, Mark Zbikowski. - The Berkeley Fast File System superblock format is identified as either
0x19540119
or0x011954
depending on version; both represent the birthday of author Marshall Kirk McKusick. - Executables for the Game Boy and Game Boy Advance handheld video game systems have a 48-byte or 156-byte magic number, respectively, at a fixed spot in the header. This magic number encodes a bitmap of the Nintendo logo.
- Old Fat binaries (containing code for both 68K processors and PowerPC processors) on Mac OS 9 contained the ASCII code for 'Joy!' (
0x4A6F7921
) as a prefix. - TIFF files begin with either "II" or "MM" depending on the byte order (II for Intel, or little endian, MM for Motorola, or big endian), followed by
0x2A00
or0x002A
(decimal 42 as a 2-byte integer in Intel or Motorola byte ordering).
The Unix program file
can read and interpret magic numbers from files.
Magic numbers in code
The term magic number also refers to the bad programming practice of using numbers directly in source code without explanation. In most cases this makes programs harder to read, understand, and maintain. Although most guides make an exception for the numbers zero and one, it is a good idea to define all other numbers in code as named constants.
For example, to shuffle the values in an array randomly, this pseudocode will do the job:
for i from 1 to 52 j := i + randomInt(53 - i) - 1 swapEntries(i, j)
where the function randomInt(x)
chooses a random integer between 1 to x, inclusive, and swapEntries(i, j)
swaps the ith and jth entries in the array. In this example, 52
is a magic number. It is considered better programming style to write:
constant int deckSize := 52 for i from 1 to deckSize j := i + randomInt(deckSize + 1 - i) - 1 swapEntries(i, j)
This is preferable for several reasons:
- It is easier to read and understand. A programmer reading the first example might wonder, What does the number
52
mean here? Why52
? The programmer might infer the meaning after reading the code carefully, but it's not obvious. Magic numbers become particularly confusing when the same number is used for different purposes in one section of code.
- It is easier to maintain. Changing the value of a magic number is error-prone, because the same value is often used several times in different places within a program. To modify the first example to shuffle a Tarot deck, which has 78 cards, a programmer might naively replace every instance of
52
in the program with78
. This would cause two problems. First, it would miss the value53
on the second line of the example, which would cause the algorithm to fail in a subtle way. Second, it would likely replace the characters52
everywhere, regardless of whether they refer to the deck size or to something else entirely, which could introduce bugs. By contrast, changing the value of thedeckSize
variable in the second example would be a simple, one-line change.
- It facilitates parameterization. For example, to generalize the above example into a procedure that shuffles a deck of any number of cards, it would be sufficient to turn
deckSize
into a parameter of that procedure. The first example would require several changes.
- It helps detect typos. Using a variable (instead of a literal) takes advantage of a compiler's checking (if any). Accidentally typing "62" instead of "52" would go undetected, whereas typing "dekSize" instead of "deckSize" would result in the compiler's warning that dekSize is undeclared.
- It can reduce typing in some IDEs. If an IDE supports code completion, it will fill in most of the variable's name from the first few letters.
Disadvantages are:
- It can increase the line length of the source code, forcing lines to be broken up if many constants are used on the same line.
- It can make debugging more difficult, especially on systems where the debugger doesn't display the values of constants.
Magic debug values
Magic debug values are specific values written to memory during allocation or deallocation, so that it will later be possible to tell whether or not they have become corrupted and to make it obvious when values taken from uninitialized memory are being used.
Memory is usually viewed in hexadecimal, so common values used are often repeated digits or hexspeak.
Famous and common examples include:
0x..FACADE
: Used by a number of RTOSes0xABABABAB
: Used by Microsoft's LocalAlloc() to mark "no man's land" guard bytes after allocated heap memory0xBAADF00D
: Used by Microsoft's LocalAlloc(LMEM_FIXED) to mark uninitialised allocated heap memory0xBADBADBADBAD
: Burroughs B6700 "uninitialized" memory (48-bit words)0xC001D00D
0xC0DEBABE
0xC0EDBABE
0xCACACACA
0xCAFEBABE
: Used as the first four bytes of every Java .class file.0xCAFECAFE
0xCAFEFEED
: Used by Sun Microsystems' Solaris debugging kernel to mark kmemfree() memory0xCCCCCCCC
: Used by Microsoft's C++ debugging heap to mark uninitialised stack memory0xCDCDCDCD
: Used by Microsoft's C++ debugging heap to mark uninitialised heap memory0xDDDDDDDD
: Used by MicroQuill's SmartHeap and Microsoft's C++ debugging heap to mark freed heap memory0xDEADBABE
: Used at the start of Silicon Graphics' IRIX arena files0xDEADBEEF
: Famously used on IBM systems such as the RS/6000, also in OPENSTEP Enterprise and the Commodore Amiga0xDEADDEAD
: A Microsoft Windows STOP Error code used when the user manually initiates the crash.0xDECAFBAD
0xEBEBEBEB
: From MicroQuill's SmartHeap0xFDFDFDFD
: Used by Microsoft's C++ debugging heap to mark "no man's land" guard bytes before and after allocated heap memory0xFEEDBABE
0xFEEDFACE
: Seen in Mach-O binaries on Apple's Mac OS X platform0xFEEEFEEE
: Used by Microsoft's HeapFree() to mark freed heap memory
Note that most of these are each 8 nibbles (32 bits) long, as most modern computers are designed to manipulate 32 bits at a time.
The prevalence of these values in Microsoft technology is no coincidence; they are discussed in detail in Steve Maguire's well-known book Writing Solid Code from Microsoft Press. He gives a variety of criteria for these values, such as:
- They should not be useful; that is, most algorithms that operate on them should be expected to do something unusual. Numbers like zero don't fit this criterion.
- They should be easily recognized by the programmer as invalid values in the debugger.
- On machines that don't have byte alignment, they should be odd numbers, so that dereferencing them as addresses causes an exception.
- They should cause an exception, or perhaps even a debugger break, if executed as code.
Since they were often used to mark areas of memory that were essentially empty, some of these terms came to be used in phrases meaning "gone, aborted, flushed from memory"; e.g. "Your program is DEADBEEF".
Pietr Brandehörst's ZUG programming language initialized memory to either 0x0000
, 0xDEAD
or 0xFFFF
in development environment and to 0x0000
in the live environment, on the basis that uninitialised variables should be encouraged to misbehave under development to trap them, but encouraged to behave in a live environment to reduce errors.
See also
Magic number section in 'File format' article