This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients David.Edelsohn, Dormouse759, hroncok, vstinner
Date 2020-01-29.01:38:37
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1580261917.4.0.459141445304.issue39460@roundup.psfhosted.org>
In-reply-to
Content
David Edelsohn:

> Output on s390x Fedora Rawhide:
> (...)
> os.stat (sec): 4386268800
> os.stat (ns): 2147483647000000000

Oh wait, ns != sec * 10**9 here. "2147483647" is 2**31-1 (INT_MAX).

It looks like a bug in fill_time() of Modules/posixmodule.c. I suspect a bug in _PyLong_FromTime_t().

On this buildbot worker, we have:

    checking size of long long... 8
    checking size of time_t... 8

So _PyLong_FromTime_t() should be implemented as:

    return PyLong_FromLongLong((long long)t);

_PyLong_FromTime_t() raw value is exported in os.stat() as os.stat(filename)[8].

Attached utime_stat_localtime2.py exposes it:

vstinner@apu$ ./python utime_stat_localtime2.py 
os.utime (sec): 4386268800
os.stat (sec int): 4386268800
os.stat (sec float): 4386268800.0
os.stat (ns): 4386268800000000000

On Fedora 31 x86-64 with GCC 9.2.1, gcc -O3, _PyLong_FromTime_t() really just calls PyLong_FromLongLong():

(gdb) disassemble _PyLong_FromTime_t
Dump of assembler code for function _PyLong_FromTime_t:
   0x0000000000521f30 <+0>:	jmp    0x457800 <PyLong_FromLongLong>
History
Date User Action Args
2020-01-29 01:38:37vstinnersetrecipients: + vstinner, David.Edelsohn, hroncok, Dormouse759
2020-01-29 01:38:37vstinnersetmessageid: <1580261917.4.0.459141445304.issue39460@roundup.psfhosted.org>
2020-01-29 01:38:37vstinnerlinkissue39460 messages
2020-01-29 01:38:37vstinnercreate