2 messages in org.python.python-bugs-list[ python-Bugs-897625 ] time.strftime ...
FromSent OnAttachments
SourceForge.netFeb 28, 2004 11:57 am 
SourceForge.netMar 1, 2004 11:48 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:[ python-Bugs-897625 ] time.strftime crashes pythonActions...
From:SourceForge.net (nore@sourceforge.net)
Date:Mar 1, 2004 11:48:59 pm
List:org.python.python-bugs-list

Bugs item #897625, was opened at 2004-02-15 13:33 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=897625&group_id=5470

Category: Python Library

Group: Python 2.4 Status: Closed Resolution: Fixed

Priority: 7 Submitted By: Tom Lynn (tlynn) Assigned to: Brett Cannon (bcannon) Summary: time.strftime crashes python

Initial Comment: On Win2k:

Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.

import time time.strftime("%a",(1900,1,1, 13,0,0, -3,0,-1))

Python dumps core. Is that (ever) expected behaviour?

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)

Date: 2004-03-01 20:49

Message: Logged In: YES user_id=357491

OK, fixed in Python 2.4 with rev. #2.140 for Modules/timemodule.c (along with changes to Doc/lib/libtime.tex as rev. 1.63, datetimemodule.c as rev. 1.70, Lib/test/test_time.py as rev. 1.16, and Lib/test/test_strftime.py as rev. 1.28).

This will break some code that does not use 1 or higher for fields in the time tuple that are supposed to be set to that (month, day, and day of year), but it was felt it was better to do a complete check on all values then on only certain values so as to make it consistent.

Since it breaks code it will not be backported.

And yes, ashtong, more data points are always helpful.

----------------------------------------------------------------------

Comment By: Graham Ashton (ashtong) Date: 2004-02-28 08:57

Message: Logged In: YES user_id=263764

Not sure if it's helpful, but here's another data point. I get the buggy behaviour on 2.3.3 on Gentoo Linux:

ratchet% python Python 2.3.3 (#1, Jan 6 2004, 09:44:50) [GCC 3.3.2 20031022 (Gentoo Linux 3.3.2-r2, propolice)] on linux2 Type "help", "copyright", "credits" or "license" for more information.

import time time.strftime("%a",(1900,1,1, 13,0,0, -3,0,-1))

Segmentation fault

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon) Date: 2004-02-21 12:01

Message: Logged In: YES user_id=357491

OK, have a solution coded up, just waiting to hear from Tim on whether a change to datetime is okay with him.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon) Date: 2004-02-17 13:59

Message: Logged In: YES user_id=357491

Should be able to deal with this cleanly by modifying gettmarg() to do some sanity checks on the values before returning and letting time_strftime() at the struct tm that gettmarg() created.

First have to check the ISO C standard, though, to make sure I don't overstep my bounds on the sanity checks (or I could just follow our own specs, but that would be too easy =).

----------------------------------------------------------------------

Comment By: Matthew Sherborne (matiu) Date: 2004-02-16 12:36

Message: Logged In: YES user_id=304464

On WinXP Home does:

import time time.strftime("%a",(1900,1,1, 13,0,0, -3,0,-1))

'\xfcI\xc1w\xf8I\xc1w\xf4I\xc1w\xf0I\xc1w\xecI\xc1w\xe8I\xc1w\xe4I\xc1w\xdcI\xc1w\xd4I\xc1w\xccI\xc1w\xc0I\xc1w\xb4I\xc1w\xacI\xc1w\xa0I\xc1w\x9cI\xc1w\x98I\xc1w\x94I\xc1w\x90I\xc1w\x8cI\xc1w\x88I\xc1w\x84I\xc1w\x80I\xc1w|I\xc1wxI\xc1wtI\xc1wpI\xc1whI\xc1w\I\xc1wTI\xc1wLI\xc1w\x8cI\xc1wDI\xc1w<I\xc1w4I\xc1w(I\xc1wI\xc1w\x14I\xc1w\x08I\xc1w\x04I\xc1w'

ActivePython 2.3.2 Build 232 (ActiveState Corp.) based on Python 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC v.1200 32 bit (Intel)] on win32

----------------------------------------------------------------------

Comment By: Matthew Sherborne (matiu) Date: 2004-02-16 12:34

Message: Logged In: YES user_id=304464

On my linux system does:

import time time.strftime("%a",(1900,1,1, 13,0,0, -3,0,-1))

'\x0e'

Python 2.3.3c1 (#2, Dec 6 2003, 16:44:56) [GCC 3.3.3 20031203 (prerelease) (Debian)] on linux2

----------------------------------------------------------------------

Comment By: Matthew Sherborne (matiu) Date: 2004-02-16 12:32

Message: Logged In: YES user_id=304464

Also, please have a look at: https://sourceforge.net/tracker/index.php?func=detail&aid=898253&group_id=5470&atid=105470

at the same time.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one) Date: 2004-02-15 17:23

Message: Logged In: YES user_id=31435

I assume this is specific to Python on Windows using Microsoft's C, since this workalike plain C program also dies with a memory error while in the bowels of MS's strftime():

#include <stdio.h> #include <time.h>

void main() { struct tm t; char buf[256]; size_t i;

t.tm_year = 1900 - 1900; t.tm_mon = 1 - 1; t.tm_mday = 1; t.tm_hour = 13; t.tm_min = 0; t.tm_sec = 0; t.tm_wday = -3; t.tm_yday = 0; t.tm_isdst = -1;

printf("calling strftime\n"); i = strftime(buf, sizeof(buf), "%a", &t); printf("i: %d\n", i); }

The problem is the negative value for tm_wday. MS strftime isn't defensive, and uses the negative tm_wday to index into nonsense memory. Ironically, if C had defined the % operator in the sane way (meaning Python's way <wink>), a negative tm_wday wouldn't have survived for the C library function to see.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-15 15:41

Message: Logged In: YES user_id=80475

It is expected. Well, now that I've confirmed it on Py2.3.3 and Py2.4, yes ;-)

Is it desirable? Heck no.

Brett, can you take a look at this?

----------------------------------------------------------------------