Mirror
/
cpython
mirror of https://github.com/python/cpython
4
1
Fork 0
Code Issues Releases Wiki Activity

Bump the magic number to avoid sharing bytecode between 2.3 and 2.4. 

Revise the long comment that explained details of the magic number
in gory detail.
This commit is contained in:
Jeremy Hylton 2004-04-01 02:45:22 +00:00
parent b67c94318e
commit d4ceb31664
1 changed files with 12 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
Python/import.c
View File

@ -19,39 +19,20 @@
extern time_t PyOS_GetLastModificationTime(char *, FILE *);
/* In getmtime.c */
/* Magic word to reject .pyc files generated by other Python versions */
/* Change for each incompatible change */
/* The value of CR and LF is incorporated so if you ever read or write
/* Magic word to reject .pyc files generated by other Python versions.
It should change for each incompatible change to the bytecode.
The value of CR and LF is incorporated so if you ever read or write
a .pyc file in text mode the magic number will be wrong; also, the
Apple MPW compiler swaps their values, botching string constants.
XXX That probably isn't important anymore.
*/
/* XXX Perhaps the magic number should be frozen and a version field
added to the .pyc file header? */
/* New way to come up with the low 16 bits of the magic number:
(YEAR-1995) * 10000 + MONTH * 100 + DAY
where MONTH and DAY are 1-based.
XXX Whatever the "old way" may have been isn't documented.
XXX This scheme breaks in 2002, as (2002-1995)*10000 = 70000 doesn't
fit in 16 bits.
XXX Later, sometimes 1 gets added to MAGIC in order to record that
the Unicode -U option is in use. IMO (Tim's), that's a Bad Idea
(quite apart from that the -U option doesn't work so isn't used
anyway).
XXX MAL, 2002-02-07: I had to modify the MAGIC due to a fix of the
UTF-8 encoder (it previously produced invalid UTF-8 for unpaired
high surrogates), so I simply bumped the month value to 20 (invalid
month) and set the day to 1. This should be recognizable by any
algorithm relying on the above scheme. Perhaps we should simply
start counting in increments of 10 from now on ?!
Apparently, there was a distinction made between even and odd
bytecodes that is related to Unicode. The details aren't clear,
but the magic number has been odd for a long time.
MWH, 2002-08-03: Removed SET_LINENO. Couldn't be bothered figuring
out the MAGIC schemes, so just incremented it by 10.
GvR, 2002-08-31: Because MWH changed the bytecode again, moved the
magic number *back* to 62011. This should get the snake-farm to
throw away its old .pyc files, amongst others.
There were a variety of old schemes for setting the magic number.
The current working scheme is to increment the previous value by
10.
Known values:
Python 1.5: 20121
@ -66,8 +47,9 @@ extern time_t PyOS_GetLastModificationTime(char *, FILE *);
Python 2.3a0: 62011
Python 2.3a0: 62021
Python 2.3a0: 62011 (!)
Python 2.4a0: 62031
*/
#define MAGIC (62011 | ((long)'\r'<<16) | ((long)'\n'<<24))
#define MAGIC (62031 | ((long)'\r'<<16) | ((long)'\n'<<24))
/* Magic word as global; note that _PyImport_Init() can change the
value of this global to accommodate for alterations of how the