Mandar Gokhale added the comment:
[Strictly speaking, this is actually issue #10563, but that was marked
superseded by the changes for this issue, hence the comment here.]
The 5-digit year still displays an extra newline in Python 2.7.11 (there's
extra whitespace on OSX as well, but that
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Committed in r87736. I opened a separate issue #10827 to address the lower
bound.
--
resolution: - fixed
stage: commit review - committed/rejected
status: open - closed
___
Georg Brandl ge...@python.org added the comment:
Thanks!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8013
___
___
Python-bugs-list mailing
STINNER Victor victor.stin...@haypocalc.com added the comment:
http://docs.python.org/library/time.html#time-y2kissues
Values 100–1899 are always illegal.
Why are these values illegal? The GNU libc accepts year in [1900-2^31; 2^31-1]
(tm_year in [-2147483648; 2147481747]). If
STINNER Victor victor.stin...@haypocalc.com added the comment:
test_time fails with an (C) assertion error on Windows: see issue #10814.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8013
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Attached patch, issue8013-pre-check.diff, checks for year range before calling
system asctime and replaces a call to ctime with a asctime(localtime(..)).
--
stage: needs patch - commit review
Added file:
SilentGhost michael.mischurow+...@gmail.com added the comment:
All tests pass and all works as documented with the latest patch on Ubuntu
(glibc 2.11).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8013
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Following Guido's response [1] to my inquiry on python-dev, I am attaching a
new patch that makes time.asctime and time.ctime produce longer than
24-character strings for large years.
[1]
Georg Brandl ge...@python.org added the comment:
The patch is wrong: it hardcodes the number of characters that the time string
has, but it can be more than 24 if the year is . (Of course, the check
for \n currently in the code is wrong too and must be fixed.)
Also, shouldn't the issue
Andreas Stührk andy-pyt...@hammerhartes.de added the comment:
The real problem with years = is that it is undefined behaviour anyway
(see e.g.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/asctime.html: the
behavior is undefined if the above algorithm would attempt to
Andreas Stührk andy-pyt...@hammerhartes.de added the comment:
Sorry, I meant years of course.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8013
___
Georg Brandl ge...@python.org added the comment:
Well, then I would have no problem with checking for that condition beforehand
and raising ValueError.
On the other hand, it seems that implementations either return a correct string
or NULL, so just erroring out in case of NULL would be fine
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
On Sun, Jan 2, 2011 at 10:52 AM, Georg Brandl rep...@bugs.python.org wrote:
..
Well, then I would have no problem with checking for that condition
beforehand and raising
ValueError.
IIRC, there was a similar bug report
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
On Sun, Jan 2, 2011 at 1:52 PM, Alexander Belopolsky
rep...@bugs.python.org wrote:
..
Well, then I would have no problem with checking for that condition
beforehand and raising
ValueError.
IIRC, there was a similar bug
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
On Sun, Jan 2, 2011 at 1:59 PM, Alexander Belopolsky
rep...@bugs.python.org wrote:
..
Hmm. My search brought up issue 10563, but the last message on that
issue says that a change has been recently made to time.asctime() to
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Committed in revision 87648.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8013
___
SilentGhost michael.mischurow+...@gmail.com added the comment:
Sasha, commit is not working. It doesn't pass test on Ubuntu and returns the
string with a trailing \n. Seems like that hunk of code is misplaced.
--
nosy: +SilentGhost
___
Python
STINNER Victor victor.stin...@haypocalc.com added the comment:
Sasha, commit is not working.
I suppose that the fix for the segfault is correct. The problem on Linux is the
new test: asc
import time; time.asctime((12345, 1, 0, 0, 0, 0, 0, 0, 0))
'Mon Jan 1 00:00:00 12345\n'
asctime() of
Georg Brandl ge...@python.org added the comment:
Tests fixed to ignore ValueError in r87656.
Both asctime() and ctime() fixed to remove newline no matter how many digits
the year has in r87657. I also took the liberty of making the error messages
consistent.
--
resolution: - fixed
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
On Sun, Jan 2, 2011 at 5:35 PM, Georg Brandl rep...@bugs.python.org wrote:
..
Both asctime() and ctime() fixed to remove newline no matter how many
digits the year has in r87657. I also took the liberty of making the error
Georg Brandl ge...@python.org added the comment:
In that case however, it's equally unsafe to not replace a \n, but still use
PyUnicode_FromString() without a size given -- you will read from random memory.
Since all implementations we have or can test have a defined behavior in one
way or
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
On Sun, Jan 2, 2011 at 6:01 PM, Georg Brandl rep...@bugs.python.org wrote:
..
Since all implementations we have or can test have a defined behavior in one
way or the other,
I think an example of an implementation that
Georg Brandl ge...@python.org added the comment:
All right, then I wonder why your checktm() doesn't check the tm_year?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8013
___
Georg Brandl ge...@python.org added the comment:
(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?)
--
___
Python tracker rep...@bugs.python.org
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
On Sun, Jan 2, 2011 at 6:10 PM, Georg Brandl rep...@bugs.python.org 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
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
On Sun, Jan 2, 2011 at 6:17 PM, Georg Brandl rep...@bugs.python.org 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?)
Georg Brandl ge...@python.org 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,
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
On Sun, Jan 2, 2011 at 6:29 PM, Georg Brandl rep...@bugs.python.org wrote:
..
You cannot have both: a safe implementation and the correct behavior with
glibc
(not Linux!) -- except if you start special-casing. Not sure
Alexander Belopolsky alexander.belopol...@gmail.com 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 rep...@bugs.python.org
http://bugs.python.org/issue8013
Georg Brandl ge...@python.org 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
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
On Sun, Jan 2, 2011 at 6:46 PM, Georg Brandl rep...@bugs.python.org 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.
--
SilentGhost michael.mischurow+...@gmail.com 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
Andreas Stührk andy-pyt...@hammerhartes.de added the comment:
It's documented under Year 2000 (Y2K) issues:
http://docs.python.org/library/time.html#time-y2kissues
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8013
Alexander Belopolsky belopol...@users.sourceforge.net 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
SilentGhost michael.mischurow+...@gmail.com 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.
--
Changes by Shashwat Anand anand.shash...@gmail.com:
--
nosy: -l0nwlf
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8013
___
___
Python-bugs-list
Sandro Tosi sandro.t...@gmail.com added the comment:
Hi Alexander, can you confirm this bug is MacOs specific? I tried with
python2.6 on a Debian sid @64 bit but I can't replicate it. Also, do you see it
only on 2.6? if so, I doubt that it will ever be fixed; f.e. on release2.7
branch I have:
Ned Deily n...@acm.org added the comment:
It's still a problem on OS X at least and is 64-bit related:
$ arch -i386 /usr/local/bin/python3.2 -c 'import
time;print(time.asctime(time.gmtime(1e12)))'
Traceback (most recent call last):
File string, line 1, in module
ValueError: timestamp out of
Changes by Ned Deily n...@acm.org:
--
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8013
___
Sandro Tosi sandro.t...@gmail.com added the comment:
Hi Ned, thanks for the fast check! I tried to applied the patch (it failed, so
it required a bit of manual editing) but when compiling I got:
/home/morph/python-dev/py3k/Modules/timemodule.c: In function ‘time_asctime’:
Andreas Stührk andy-pyt...@hammerhartes.de added the comment:
Updated patch against py3k branch.
--
nosy: +Trundle
Added file: http://bugs.python.org/file20213/issue8013_py3k.diff
___
Python tracker rep...@bugs.python.org
Ned Deily n...@acm.org added the comment:
Thanks for the py3k patch. I am also attaching a refreshed patch for current
2.7. They both fix the segfaults when built and run on OS X 10.6 64-bit.
Since the patches change timemodule to use asctime_r, which AFAICT is not used
elsewhere in the
Wilfredo Sanchez wsanc...@wsanchez.net added the comment:
I get this on Python 2.6, not 2.5.
And it seems to be limited to 64-bit.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8013
___
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
Looks like a case of missing null check. Patch attached.
--
keywords: +patch
nosy: +Alexander.Belopolsky
Added file: http://bugs.python.org/file16359/issue8013.diff
___
Python
44 matches
Mail list logo
