[Python-Dev] Win32 build (was: RE: [Patches] From comp.lang.python: A compromise on case-sensitivity)

Trent Mick trentm@activestate.com
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 <gstein@lyra.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/


Trent

-- 
Trent Mick
trentm@activestate.com


Return-Path: <trentm@molotok.activestate.com>
Delivered-To: python-dev@python.org
Received: from molotok.activestate.com (molotok.activestate.com [199.60.48.208])
	by dinsdale.python.org (Postfix) with ESMTP id C7A5F1CD69
	for <python-dev@python.org>; 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 python-dev@python.org; Fri, 26 May 2000 11:49:22 -0700
Resent-Message-Id: <200005261849.LAA01949@molotok.activestate.com>
Date: Fri, 26 May 2000 11:39:40 -0700
From: Trent Mick <trentm@activestate.com>
To: Peter Funk <pf@artcom-gmbh.de>
Subject: Re: [Python-Dev] Proposal: .pyc file format change
Message-ID: <20000526113940.B32427@activestate.com>
References: <200005251551.KAA11897@cj20424-a.reston1.va.home.com> <m12vFOo-000DieC@artcom0.artcom-gmbh.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <m12vFOo-000DieC@artcom0.artcom-gmbh.de>
Resent-From: trentm@activestate.com
Resent-Date: Fri, 26 May 2000 11:49:22 -0700
Resent-To: python-dev@python.org
Resent-Sender: trentm@molotok.activestate.com
Sender: python-dev-admin@python.org
Errors-To: python-dev-admin@python.org
X-BeenThere: python-dev@python.org
X-Mailman-Version: 2.0beta3
Precedence: bulk
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
> 
> Proposal:
> 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
(tm)).

CHeers,
Trent

-- 
Trent Mick
trentm@activestate.com