[Python-Dev] Win32 build (was: RE: [Patches] From comp.lang.python: A compromise on case-sensitivity)
Fri, 26 May 2000 11:55:55 -0700
On Sat, May 27, 2000 at 08:46:44AM -0400, Barry A. Warsaw wrote:
> >>>>> "GS" == Greg Stein <firstname.lastname@example.org> writes:
> GS> On Fri, 26 May 2000, Tim Peters wrote:
> >> ... PS: Barry's exception patch appears to have broken the CVS
> >> Windows build (nothing links anymore; all the PyExc_xxx symbols
> >> aren't found; no time to dig more now).
> GS> The .dsp file(s) need to be updated to include the new
> GS> _exceptions.c file in their build and link step. (the symbols
> GS> moved there)
> GS> IMO, it seems it would be Better(tm) to put _exceptions.c into
> GS> the Python/ directory. Dependencies from the core out to
> GS> Modules/ seems a bit weird.
> Guido made the suggestion to move _exceptions.c to exceptions.c any
> way. Should we move the file to the other directory too? Get out
> your plusses and minuses.
+1 moving exceptions.c to Python/
Received: from molotok.activestate.com (molotok.activestate.com [18.104.22.168])
by dinsdale.python.org (Postfix) with ESMTP id C7A5F1CD69
for <email@example.com>; Fri, 26 May 2000 14:49:28 -0400 (EDT)
Received: (from trentm@localhost)
by molotok.activestate.com (8.9.3/8.9.3) id LAA01949
for firstname.lastname@example.org; Fri, 26 May 2000 11:49:22 -0700
Date: Fri, 26 May 2000 11:39:40 -0700
From: Trent Mick <email@example.com>
To: Peter Funk <firstname.lastname@example.org>
Subject: Re: [Python-Dev] Proposal: .pyc file format change
References: <200005251551.KAA11897@cj20424-a.reston1.va.home.com> <m12vFOo-000DieC@artcom0.artcom-gmbh.de>
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
Resent-Date: Fri, 26 May 2000 11:49:22 -0700
List-Id: Python core developers <python-dev.python.org>
On Fri, May 26, 2000 at 10:23:18AM +0200, Peter Funk wrote:
> [Guido van Rossum]:
> > Given Christian Tismer's testimonial and inspection of marshal.c, I
> > think Peter's small patch is acceptable.
> > A bigger question is whether we should freeze the magic number and add
> > a version number. In theory I'm all for that, but it means more
> > changes; there are several tools (e.c. Lib/py_compile.py,
> > Tools/freeze/modulefinder.py and Tools/scripts/checkpyc.py) that have
> > intimate knowledge of the .pyc file format that would have to be
> > modified to match.
> > The current format of a .pyc file is as follows:
> > bytes 0-3 magic number
> > bytes 4-7 timestamp (mtime of .py file)
> > bytes 8-* marshalled code object
> The future format (Python 1.6 and newer) of a .pyc file should be as follows:
> bytes 0-3 a new magic number, which should be definitely frozen in 1.6.
> bytes 4-7 a version number (which should be == 1 in Python 1.6)
> bytes 8-11 timestamp (mtime of .py file) (same as earlier)
> bytes 12-* marshalled code object (same as earlier)
This may be important: timestamps (as represented by the time_t type) are 8
bytes wide on 64-bit Linux and Win64. However, it will be a while (another 38
years) before time_t starts overflowing past 31 bits (it is a signed value).
The use of a 4 byte timestamp in the .pyc files constitutes an assumption
that this will fit in 4 bytes. The best portable way of handling this issue
(I think) is to just add an overflow check in import.c where
PyOS_GetLastModificationTime (which now properly return time_t) that raises
an exception if the time_t return value from overflows 4-bytes.
I have been going through the Python code looking for possible oveflow cases
for Win64 and Linux64 of late so I will submit these patches (Real Soon Now