In computer programming, a magic number is any of the following:
The term magic number or magic constant refers to the anti-pattern of using numbers directly in source code. This breaks one of the oldest rules of programming, dating back to the COBOL, FORTRAN and PL/1 manuals of the 1960s.[1]
In the following example that computes the price after tax, 1.05 is considered a magic number:
1.05
price_tax = 1.05 * price
The use of unnamed magic numbers in code obscures the developers' intent in choosing that number,[2] increases opportunities for subtle errors, and makes it more difficult for the program to be adapted and extended in the future.[3] As an example, it is difficult to tell whether every digit in 3.14159265358979323846 is correctly typed, or if the constant can be truncated to 3.14159 without affecting the functionality of the program with its reduced precision. Replacing all significant magic numbers with named constants (also called explanatory variables) makes programs easier to read, understand and maintain.[4]
3.14159265358979323846
3.14159
The example above can be improved by adding a descriptively named variable:
TAX = 0.05 price_tax = (1.0 + TAX) * price
Names chosen to be meaningful in the context of the program can result in code that is more easily understood by a maintainer who is not the original author (or even by the original author after a period of time).[5] An example of an uninformatively named constant is int SIXTEEN = 16, while int NUMBER_OF_BITS = 16 is more descriptive.
int SIXTEEN = 16
int NUMBER_OF_BITS = 16
The problems associated with magic 'numbers' described above are not limited to numerical types and the term is also applied to other data types where declaring a named constant would be more flexible and communicative.[1] Thus, declaring const string testUserName = "John" is better than several occurrences of the 'magic value' "John" in a test suite.
const string testUserName = "John"
"John"
For example, if it is required to randomly shuffle the values in an array representing a standard pack of playing cards, this pseudocode does the job using the Fisher–Yates shuffle algorithm:
for i from 1 to 52 j := i + randomInt(53 - i) - 1 a.swapEntries(i, j)
where a is an array object, the function randomInt(x) chooses a random integer between 1 and x, inclusive, and swapEntries(i, j) swaps the ith and jth entries in the array. In the preceding example, 52 and 53 are magic numbers, also not clearly related to each other. It is considered better programming style to write the following:
a
randomInt(x)
swapEntries(i, j)
52
53
int deckSize:= 52 for i from 1 to deckSize j := i + randomInt(deckSize + 1 - i) - 1 a.swapEntries(i, j)
This is preferable for several reasons:
deckSize
dekSize
function shuffle (int deckSize) for i from 1 to deckSize j := i + randomInt(deckSize + 1 - i) - 1 a.swapEntries(i, j)
Disadvantages are:
deckSize + 1
In some contexts, the use of unnamed numerical constants is generally accepted (and arguably "not magic"). While such acceptance is subjective, and often depends on individual coding habits, the following are common examples:
for (int i = 0; i < max; i += 1)
isEven = (x % 2 == 0)
%
circumference = 2 * Math.PI * radius
d = b^2 − 4*a*c
(f(x) ** 2 + f(y) ** 2) ** 0.5
The constants 1 and 0 are sometimes used to represent the Boolean values true and false in programming languages without a Boolean type, such as older versions of C. Most modern programming languages provide a boolean or bool primitive type and so the use of 0 and 1 is ill-advised. This can be more confusing since 0 sometimes means programmatic success (when -1 means failure) and failure in other cases (when 1 means success).
boolean
bool
In C and C++, 0 represents the null pointer. As with Boolean values, the C standard library includes a macro definition NULL whose use is encouraged. Other languages provide a specific null or nil value and when this is the case no alternative should be used. The typed pointer constant nullptr has been introduced with C++11.
NULL
null
nil
nullptr
Format indicators were first used in early Version 7 Unix source code.[citation needed]
Unix was ported to one of the first DEC PDP-11/20s, which did not have memory protection. So early versions of Unix used the relocatable memory reference model.[6] Pre-Sixth Edition Unix versions read an executable file into memory and jumped to the first low memory address of the program, relative address zero. With the development of paged versions of Unix, a header was created to describe the executable image components. Also, a branch instruction was inserted as the first word of the header to skip the header and start the program. In this way a program could be run in the older relocatable memory reference (regular) mode or in paged mode. As more executable formats were developed, new constants were added by incrementing the branch offset.[7]
In the Sixth Edition source code of the Unix program loader, the exec() function read the executable (binary) image from the file system. The first 8 bytes of the file was a header containing the sizes of the program (text) and initialized (global) data areas. Also, the first 16-bit word of the header was compared to two constants to determine if the executable image contained relocatable memory references (normal), the newly implemented paged read-only executable image, or the separated instruction and data paged image.[8] There was no mention of the dual role of the header constant, but the high order byte of the constant was, in fact, the operation code for the PDP-11 branch instruction (octal 000407 or hex 0107). Adding seven to the program counter showed that if this constant was executed, it would branch the Unix exec() service over the executable image eight byte header and start the program.
Since the Sixth and Seventh Editions of Unix employed paging code, the dual role of the header constant was hidden. That is, the exec() service read the executable file header (meta) data into a kernel space buffer, but read the executable image into user space, thereby not using the constant's branching feature. Magic number creation was implemented in the Unix linker and loader and magic number branching was probably still used in the suite of stand-alone diagnostic programs that came with the Sixth and Seventh Editions. Thus, the header constant did provide an illusion and met the criteria for magic.
In Version Seven Unix, the header constant was not tested directly, but assigned to a variable labeled ux_mag[9] and subsequently referred to as the magic number. Probably because of its uniqueness, the term magic number came to mean executable format type, then expanded to mean file system type, and expanded again to mean any type of file.
Magic numbers are common in programs across many operating systems. Magic numbers implement strongly typed data and are a form of in-band signaling to the controlling program that reads the data type(s) at program run-time. Many files have such constants that identify the contained data. Detecting such constants in files is a simple and effective way of distinguishing between many file formats and can yield further run-time information.
CAFEBABE
CAFED00D
47
49
46
38
39
61
37
FF
D8
D9
4A
00
45
78
69
66
89
50
4E
0D
0A
1A
4D
54
68
64
23
21
7F
4C
25
44
5A
19
01
55
AA
6F
79
2A
FE
EF
BB
BF
42
43
D0
CF
11
E0
4B
03
04
7A
BC
AF
27
1C
The Unix utility program file can read and interpret magic numbers from files, and the file which is used to parse the information is called magic. The Windows utility TrID has a similar purpose.
file
"\xFFSMB"
05
4F
57
41
E3
C5
D4
0xD9B4BEF9
0xDAB5BFFA
80
16
0x63
0x82
0x53
0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n
258EAFA5-E914-47DA-95CA-C5AB0DC85B11
Magic numbers are common in API functions and interfaces across many operating systems, including DOS, Windows and NetWare:
0000
1234
55 AA
This is a list of limits of data storage types:[15]
It is possible to create or alter globally unique identifiers (GUIDs) so that they are memorable, but this is highly discouraged as it compromises their strength as near-unique identifiers.[16][17] The specifications for generating GUIDs and UUIDs are quite complex, which is what leads to them being virtually unique, if properly implemented.[18]
Microsoft Windows product ID numbers for Microsoft Office products sometimes end with 0000-0000-0000000FF1CE ("OFFICE"), such as {90160000-008C-0000-0000-0000000FF1CE}, the product ID for the "Office 16 Click-to-Run Extensibility Component".
0000-0000-0000000FF1CE
90160000-008C-0000-0000-0000000FF1CE
Java uses several GUIDs starting with CAFEEFAC.[19]
CAFEEFAC
In the GUID Partition Table of the GPT partitioning scheme, BIOS Boot partitions use the special GUID {21686148-6449-6E6F-744E-656564454649}[20] which does not follow the GUID definition; instead, it is formed by using the ASCII codes for the string "Hah!IdontNeedEFI" partially in little endian order.[21]
21686148-6449-6E6F-744E-656564454649
Hah!IdontNeedEFI
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 memorable repeating or hexspeak values are common. Numerically odd values may be preferred so that processors without byte addressing will fault when attempting to use them as pointers (which must fall at even addresses). Values should be chosen that are away from likely addresses (the program code, static data, heap data, or the stack). Similarly, they may be chosen so that they are not valid codes in the instruction set for the given architecture.
Since it is very unlikely, although possible, that a 32-bit integer would take this specific value, the appearance of such a number in a debugger or memory dump most likely indicates an error such as a buffer overflow or an uninitialized variable.
Famous and common examples include:
00008123
..FACADE
1BADB002
8BADF00D
A5A5A5A5
A5
ABABABAB
ABADBABE
ABBABABE
ABADCAFE
B16B00B5
BAADF00D
BAAAAAAD
BAD22222
BADBADBADBAD
BADC0FFEE0DDF00D
BADDCAFE
BBADBEEF
BEBEBEBE
BEEFCACE
C00010FF
CAFEFEED
CCCCCCCC
CC
CDCDCDCD
0D15EA5E
DDDDDDDD
DEAD10CC
DEADBABE
DEADBEEF
DEADCAFE
DEADC0DE
DEADFA11
DEADF00D
DEFEC8ED
DEADDEAD
D00D2BAD
D00DF33D
EBEBEBEB
FADEDEAD
FDFDFDFD
FEE1DEAD
FEEDFACE
Used by VLC player and some IP cameras in RTP/RTCP protocol, VLC player sends four bytes in the order of the endianness of the system. Some IP cameras expect the player to send this magic number and do not start the stream if it is not received.
FEEEFEEE
Most of these are 32 bits long – the word size of most 32-bit architecture computers.
The prevalence of these values in Microsoft technology is no coincidence; they are discussed in detail in Steve Maguire's book Writing Solid Code from Microsoft Press. He gives a variety of criteria for these values, such as:
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".[citation needed]