[issue8013] time.asctime segfaults when given a time in the far future

Alexander Belopolsky added the comment: On Sun, Jan 2, 2011 at 6:10 PM, Georg Brandl wrote: .. > All right, then I wonder why your checktm() doesn't check the tm_year? It is not mine. I thought it did. I might have missed that when I reviewed the patch or there was a reason for that at the t

[issue8013] time.asctime segfaults when given a time in the far future

Alexander Belopolsky added the comment: On Sun, Jan 2, 2011 at 6:17 PM, Georg Brandl wrote: .. > (What I mean is that overwriting \n or not, the code is unsafe, so the check > must be > done beforehand.  Why should that be left to 3.3?) Reading beyond a buffer is somewhat safer than writing,

[issue8013] time.asctime segfaults when given a time in the far future

Georg Brandl added the comment: You cannot have both: a safe implementation and the correct behavior with glibc (not Linux!) -- except if you start special-casing. Not sure that's worth it. Note that time.asctime() is documented in time.rst to return a 24-character string, so what it current

[issue8278] os.utime doesn't allow a atime (Last Access) which is 27 years in the future.

Martin v. Löwis added the comment: The patch looks still fine. The only concern is that the test probably fails on FAT, but I think that's acceptable. -- ___ Python tracker ___

[issue10810] logging.handlers.TimedRotatingFileHandler.__init__(): ST_MTIME NameError

Martin v. Löwis added the comment: Hmm. I wonder why the code doesn't use the st_mtime field. We should really deprecate the stat module. -- nosy: +loewis ___ Python tracker __

[issue8278] os.utime doesn't allow a atime (Last Access) which is 27 years in the future.

Amaury Forgeot d'Arc added the comment: > The only concern is that the test probably fails on FAT The patch does not show it, but I've put the test under a 'if get_file_system(support.TESTFN) == "NTFS"' -- ___ Python tracker

[issue8013] time.asctime segfaults when given a time in the far future

Alexander Belopolsky added the comment: On Sun, Jan 2, 2011 at 6:29 PM, Georg Brandl wrote: .. > You cannot have both: a safe implementation and the correct behavior with > glibc > (not Linux!) -- except if you start special-casing.  Not sure that's worth it. > That's the reason why this and t

[issue8013] time.asctime segfaults when given a time in the far future

Alexander Belopolsky added the comment: .. > My plan was to pick the low-hanging fruit (the null check) for 3.3 and s/3.3/3.2/ -- ___ Python tracker ___

[issue8013] time.asctime segfaults when given a time in the far future

Georg Brandl added the comment: > There is a long tradition in keeping OS functions' > wrappers thin with an expectation that application programmers will > know the limitations/quirks of their target OSes. Sorry, but that does not apply if we trigger undefined behavior which is inherently unsa

[issue8013] time.asctime segfaults when given a time in the far future

Alexander Belopolsky added the comment: On Sun, Jan 2, 2011 at 6:46 PM, Georg Brandl wrote: .. > I don't see the range checking as particularly challenging; I'm sure you can > get it done in time for 3.2. Will do. -- ___ Python tracker

[issue8013] time.asctime segfaults when given a time in the far future

SilentGhost added the comment: I'm not sure that whether it's related to the current issue, but asctime doesn't seem to accept years < 1900. Which might be fair enough, has this been documented. -- ___ Python tracker

[issue7995] On Mac / BSD sockets returned by accept inherit the parent's FD flags

Martin v. Löwis added the comment: I like the logic of Antoine's patch much better (basing this on whether the listening socket had a timeout). I wonder whether it's correct though if there is a defaulttimeout: shouldn't it then leave the timeout on the socket instead? -- ___

[issue10798] test_concurrent_futures fails on FreeBSD

Martin v. Löwis added the comment: Is this really the time for restructuring tests? I think such activity should wait until after the 3.2 release. -- ___ Python tracker ___ ___

[issue8013] time.asctime segfaults when given a time in the far future

Andreas Stührk added the comment: It's documented under "Year 2000 (Y2K) issues": http://docs.python.org/library/time.html#time-y2kissues -- ___ Python tracker ___ _

[issue8013] time.asctime segfaults when given a time in the far future

Alexander Belopolsky added the comment: Backported in r87664 (2.6), r87663 (2.7) and r87662 (3.1). Reopening to implement bounds checking for 3.2. Note that for time.asctime, checking the year range is trivial, but for time.ctime it is not because year is not computed in python code. One so

[issue8013] time.asctime segfaults when given a time in the far future

SilentGhost added the comment: yes, sorry. what I meant to say is that fixing only upper bound for the year (according to CERT recommendation cited above) and leaving the lower bound in its current state is somewhat unsatisfactory. -- ___ Python tr

[issue10798] test_concurrent_futures fails on FreeBSD

Brian Quinlan added the comment: The tests are currently flaky on Windows and I'd like to fix that before the release. But I don't have the bandwidth to debug the Call() abstraction used in the tests before 3.2 RC1. You can see the test change here: http://svn.python.org/view/python/branches/

[issue10798] test_concurrent_futures fails on FreeBSD

Martin v. Löwis added the comment: Thanks for the review, committed as r87665. Fixing flaky tests is fine, of course. -- ___ Python tracker ___

[issue10798] test_concurrent_futures fails on FreeBSD

Martin v. Löwis added the comment: Follow-up: I have disabled test_all_completed_some_already_completed in r87667, as I couldn't figure out why it hangs. -- ___ Python tracker

[issue8278] os.utime doesn't allow a atime (Last Access) which is 27 years in the future.

Amaury Forgeot d'Arc added the comment: Committed r87666 (py3k), I'll backport to 3.1 and 2.7. -- resolution: accepted -> fixed status: open -> pending ___ Python tracker ___ ___

[issue10810] logging.handlers.TimedRotatingFileHandler.__init__(): ST_MTIME NameError

Vinay Sajip added the comment: It's just old code which just never got changed. I will change 3.2 to use the posix.stat_result attributes and remove the stat import, but I'll wait until after 3.2 is released. -- ___ Python tracker

[issue10810] logging.handlers.TimedRotatingFileHandler.__init__(): ST_MTIME NameError

Vinay Sajip added the comment: Er, I meant to say "I'll change py3k ... after 3.2 is released". -- ___ Python tracker ___ ___ Python-

[issue8278] os.utime doesn't allow a atime (Last Access) which is 27 years in the future.

Amaury Forgeot d'Arc added the comment: Merged into release31-maint (r87668) and release27-maint (r87669) -- status: pending -> closed ___ Python tracker ___

[issue10809] complex() comments wrongly say it supports NaN and inf

Andrew Dalke added the comment: Well that's ... interesting. While I compiled 2.7 and was looking at the 2.7 code my tests were against 2.6. Python 2.7 (trunk:74969:87651M, Jan 2 2011, 21:58:12) [GCC 4.2.1 (Apple Inc. build 5664)] on darwin Type "help", "copyright", "credits" or "license"

[issue10811] sqlite segfault with generators

New submission from Erick Tryzelaar : I found that the sqlite3 function executemany module crashes when passed in a generator that it iself is executing a query. It looks like this confuses the statement cache, and causes it to get cleared inappropriately in this case. I've attached a file tha

[issue10060] python.exe crashes or hangs on help() modules when bad modules found

Dev Player added the comment: import win32ui from win32ui import GetMainFrame dir(win32ui.GetMainFrame) ['__call__', '__class__', '__cmp__', '__delattr__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__module__', '__n

[issue10060] python.exe crashes or hangs on help() modules when bad modules found

Dev Player added the comment: from GetMainFrame import GetWindowText Traceback (most recent call last): File "", line 1, in ImportError: No module named GetMainFrame Also, I installed from the MS-Windows installer file: pywin32-214.win32-py2.7.exe not from "pywin32-214.zip" which I think i

[issue10811] sqlite segfault with generators

Changes by Antoine Pitrou : -- assignee: -> ghaering nosy: +ghaering ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubsc

[issue10805] traceback.print_exception throws AttributeError when exception is None

Changes by Antoine Pitrou : -- nosy: +pitrou versions: +Python 3.2 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue10060] python.exe crashes or hangs on help() modules when bad modules found

Dev Player added the comment: Oh I am running on an Intel Pentium 4 3.2GHz/3.2Ghz. Windows XP Pro SP3 32 bit So I presume I should not have used the AMD 64 versions of course. http://sourceforge.net/projects/pywin32/files/pywin32/Build%20214/ -- ___

[issue8013] time.asctime segfaults when given a time in the far future

Changes by Shashwat Anand : -- nosy: -l0nwlf ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue4953] cgi module cannot handle POST with multipart/form-data in 3.0

Changes by Shashwat Anand : -- nosy: -l0nwlf ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue4953] cgi module cannot handle POST with multipart/form-data in 3.0

Glenn Linderman added the comment: Peter, it seems that detach is relatively new (3.1) likely the code samples and suggestions that I had found to cure the problem predate that. While I haven't yet tried detach, your code doesn't seem to modify stdin, so are you suggesting, really... sys

[issue4953] cgi module cannot handle POST with multipart/form-data in 3.0

Glenn Linderman added the comment: Rereading the doc link I pointed at, I guess detach() is part of the new API since 3.1, so doesn't need to be checked for in 3.1+ code... but instead, may need to be coded as: try: sys.stdin = sys.stdin.detach() except UnsupportedOperation:

Re: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing

If you provide some tests augumenting the currently existing tests test_htmlparser.py and also ensure that no existing test breaks, it would be help better to review the patch. I do see some changes made to the regex and parsing. So tests would definitely help. ___

[issue10788] test_logging failure

Brian Quinlan added the comment: Fixed in r87673. -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-b

[issue10737] test_concurrent_futures failure on Windows

Brian Quinlan added the comment: Fixed in r87673. -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-b

[issue10028] test_concurrent_futures fails on Windows Server 2003

Brian Quinlan added the comment: Fixed in r87673. -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-b

<    1   2