mirrors/cpython
1
0
Fork 0
mirror of https://github.com/python/cpython.git synced 2025-09-26 18:29:57 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 10

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

Browse source 
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
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 *); extern time_t PyOS_GetLastModificationTime(char *, FILE *);
/* In getmtime.c */ /* In getmtime.c */
/* Magic word to reject .pyc files generated by other Python versions */ /* Magic word to reject .pyc files generated by other Python versions.
/* Change for each incompatible change */ 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
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 a .pyc file in text mode the magic number will be wrong; also, the
Apple MPW compiler swaps their values, botching string constants. 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 Apparently, there was a distinction made between even and odd
UTF-8 encoder (it previously produced invalid UTF-8 for unpaired bytecodes that is related to Unicode. The details aren't clear,
high surrogates), so I simply bumped the month value to 20 (invalid but the magic number has been odd for a long time.
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 ?!
MWH, 2002-08-03: Removed SET_LINENO. Couldn't be bothered figuring There were a variety of old schemes for setting the magic number.
out the MAGIC schemes, so just incremented it by 10. The current working scheme is to increment the previous value 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.
Known values: Known values:
Python 1.5: 20121 Python 1.5: 20121
@ -66,8 +47,9 @@ extern time_t PyOS_GetLastModificationTime(char *, FILE *);
Python 2.3a0: 62011 Python 2.3a0: 62011
Python 2.3a0: 62021 Python 2.3a0: 62021
Python 2.3a0: 62011 (!) 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 /* Magic word as global; note that _PyImport_Init() can change the
value of this global to accommodate for alterations of how the value of this global to accommodate for alterations of how the